How to start a deployment using the API

[martin]

I am used to the Otto v3 Migrator database and I have in the past managed to customize this database to work according to the needs I have. However since the application has changed and since I need to execute the migration based on certain events that are controlled through FileMaker scripts (and since I can’t alter the Migrator/OttoDeploy database anymore), I understand that I now have to use the API to start the deployments. What’s published here OttoFMS Developer API looks a bit confusing to me so I would appreciate if you help me to confirm that I get everything right - and provide some guidance - before I invest more time on these tests.

Let’s say I have one development server and multiple production environments. If I had to execute the scripts through the production environments, is your recommendation to first create the build in the development server and then use that Build ID to download the file? So I need both to pull the Build ID from each of these production servers to start the migration? Is that Build created in the development server or is it in each individual production server?

In case it helps, everything which I’m saying is based on what you wrote in the link above. Until now, I was just indicating to “connect to the development server and download the database from there” but it appears that it’s not that simple when it comes to the OttoFMS API, or at least all these options require additional configuration. otto4 and url seem to be the closest ones to that I wrote:

[toddgeist]

Hi Martin,

You can alter the OttoDeploy database if you want to. It is completely unlocked. You will loose those changes if you decide to automatically upgrade the schema file, next time there is an update. So far there has only been one schema migration.

You can use the OttoDeveloper API as you point out. The JSON payload is quite complex, BUT, you can also OttoDeploy to create the deployment JSON. Setup your deployment as you need it and then click the three dots in the upper right

That will give you the JSON object that you need to send to your destination server. That makes it quite a bit easier.

Before you spend a lit of time doing something custom, I would spend some time with the docs and maybe try out some test deployments. The reason is that I don’t think many people have had to build something custom, despite something 7000 databases are getting migrated a month with OttoFMS. That is to say your case maybe covered.

Did you get to the part of the docs where we cover the different deployment patterns, and builds?

Builds | OttoFMS

Deployment Patterns | OttoFMS

Advanced Options | OttoFMS

These may help you understand the differences between Otto3 and OttoFMS.

But in short. You can run a Build, which you can think of as a way to prepare a “Version” of your application, and then deploy that Build, designated by its id ,to as many Production servers as you want. When configuring the deployment you choose the dev server as the source, and select Build ID from the drop down.
(Make sure you have advanced options turned on.)

You can if you want to, just use “just in time” builds which are the default, and the most like Otto3, but that would Build the same set of source files for ever deployment to a production server.

Let me us know if you think have a case where you truly have to do something custom. Give us the details, and we will probably be able to point you in the right direction.

Todd

[martin]

Thank you @toddgeist for you reply.

Yes I did notice that the OttoDeploy database is fully unlocked. However it was built differently and it’s not “clearly” structured in regards to how the scripts execute the actions… While the Migrator DB let the user execute specific action-scripts without getting involved in what Otto does, this other solution I believe it uses different techniques. Maybe it’s all about knowing which OttoDeploy script would start the deployment similar to what Start Scheduled Migration { MigrationId } does in the Migrator?

As of the documentation that you shared with me, yes I had read most of it and indeed the use I have is covered in the Deployment Patterns article. However the explanation it provides speaks mainly if not only about OttoDeploy and even though it’s useful (and it actually let me already test the deployments in the OttoDeploy environment) what I am now trying to design and implement is how this whole process would interact when it comes to us deciding when to execute the migration. In other words, these deployments we need to execute are not going to be scheduled in advance and we don’t want to manually interact with the servers of course, so I am basically trying to find the ideal way to start the deployment when the script considers it needs to start.

[toddgeist]

Hi Martin.

I decided to publish a blog post on how to do this. It isn’t quite ready to go out but here here is the video, and the file I used to do it.

CustomDeploy.fmp12.zip (102.8 KB)

Todd

[martin]

Thank you again, @toddgeist! I really appreciate your help. The video is very clear and provides the answers and guidance I was hoping for. I’ll test it out, and I’m optimistic this will be enough!