Recurring Deployments

Is it possible to schedule a recurring deployment (e.g., weekly)?

Hello Dave,

Currently this is not possible, however it is a feature we are planning on adding to the system.

Do you mind me asking what you’re planning on running as a recurring deployment? We’re still working through the use cases for this feature.

-Kyle

I also like the functionality to have recurring deployments. Our use case is a client where every Monday night at 9:15pm they have a scheduled outage. We push the latest version of the system we’ve been working on at that time. We know we have to have all changes ready to go by then so we develop accordingly. With Ottov3, a scheduled deployment would create a scheduled script that referenced Migration ID and that script would remain after the migration. We just set the scheduled deployment script Otto created in the FM Admin Console to kick off every Monday night. If for some reason we had to skip a week we would just adjust the schedule to not run till the next week. That system worked very well for us.

In Otto4, it looks like it still creates a scheduled script but that script is calling a system script and then the scheduled script is deleted after the migration is complete so we lose that workaround we had in v3.

Thanks for all the feedback. It is very helpful.

We will be adding this in the near future. We are pretty sure we can improve on what was available in version 3.

Stay tuned

Todd

1 Like

We do also use/need recurring deployments.
First of all during a development process (Dev → Staging), where we migrate every night into a staging/testing version.
For that purpose we created a deployment and duplicated the created server script on the FMS Admin console (so it creates a new job with a new ID that will not be deleted after the job has been running). Additionally we changed the time schedule (every night at 3am) and saved the job.
Manual start of that job works well and the migration is done.
But when the job starts in the scheduled time slot, it dies right away.
Event.Log excerpt:
…
|2024-03-28 03:00:00.360 +0100|Informationen|148|server.name Zeitplan OTTO_mig (daily) wird ausgefĂĽhrt.|
|2024-03-28 03:00:02.046 +0100|Informationen|688|server.name Zeitplan OTTO_mig (daily) hat das Systemscript otto-cli.exe mit Prozess-ID 1160 gestartet.|
|2024-03-28 03:00:03.155 +0100|Informationen|152|server.name Zeitplan OTTO_mig (daily) abgebrochen; Abbruch durch Benutzer.|
|2024-03-28 03:00:03.155 +0100|Informationen|126|server.name Zeitplan OTTO_mig (daily) fĂĽr 29.03.2024 03:00 eingeplant.|
…
Although it says “cancelled by user”, it must have another reason.

Single not changed scheduled jobs run as expected.

Does anyone have an explanation for this, maybe a solution to the problem?

BR.
Martin

Hi Martin,

Welcome to the community.

Sorry but right now, what you are trying to do won’t work. This is a known limitation. It isn’t as simple as just changing the script recurring. There is a bit more that we need to do. This will get addressed very very soon.

As a work-a-round… If you wanted to use the Develop API, you could create a little FileMaker File with a Script that sends the same deployment via an Insert From Url script step. And run that every night.

OttoDeploy will give you the JSON payload you need to send.
TG2024-03-28 at 06.00.45

Todd

Hi Todd

Thanks a lot.
I will try your suggestion.
Will let you know.
BR.
Martin

Hi Todd
Sorry to bother you again about this, but maybe you can lead me in the right direction.
I created a script with an InsertFromURL-script step.
Endpoint: myserver.tld/otto/api/deployment
In the Curl option I set the authentication and added the json from OttoDeploy.
The callback says: HTTP Error 411. The request must be chunked or have a content length.
I added “Content-Length” to the Curl Header but still get the same error.

Do you happen to have a working example at hand?

Happy Easter :slight_smile:
Martin

Hey Martin

I don’t have a working script at hand but I have something the might make it easier for to send HTTP Scripts

Check out this file.

mfm-HTTP.fmp12 (836 KB)

It has a script called HTTP in it. You can use it to make HTTP requests using JSON instead of trying to construct curl commands which can be difficult.

This what we use always. We almost never use the Insert From Url Script step. It has been in widespread use for maybe 8 years. It has probably been called over a billion times by now.

Here is an old blog post about it

Let us know if that helps

Thanks

Todd

Upvote for this feature please :-).

Our usecase is weaning the dev process away from live development. The solution requires a lot of on-the-go adjustments (hot patches) and maintaining these across two environments while developing larger features became so problematic that we abandoned the Dev environment, simply isolating new development from users. We now would like to trial nightly deployments so that standard turn around for a non-urgent hot patch is 24 hours. For urgent hot patches or fixes the client can wear the overhead of replicating across the two environments.

2 Likes

Hey y’all,

This feature seems like something a number of y’all are looking for. As Todd called out, you can fully customize the cadence of a deployment using a Filemaker script and the deployment JSON. However, we are investigating whether this is something that we could reasonably include with OttoFMS. I have a few questions for y’all about how this feature might work.

  1. Would you want to set up the schedule through OttoDeploy when you schedule the deployment initially, and then be able to edit the schedule later? Or would you rather do the same system OttoDeploy already has and just be able to make the schedule recurring in the admin console and have it work?
  2. Do you want to see the scheduled deployments in the OttoFMS console? I could see the recurring deployment feature either showing you a single scheduled deployment in the OttoFMS console or showing you no scheduled deployment in the console and it would simply run a new deployment when your schedule runs (this would be similar to how the FileMaker script works since you would essentially be kicking off a new deployment at the time of the schedule running rather than triggering a pre-scheduled deployment).
  3. How would you want to handle changes to the scheduled recurring deployment? Depending on how we implement this you would either have to delete and recreate the recurring deployment or we could probably get some sort of stored deployment that you could edit.

Thanks y’all!

-Kyle

1 Like

Thanks Kyle, great to have you pick up and run with these thoughts.

  1. I would be content with either of those - it’s nice to have it all managed in one spot (within OttoDeploy), but I want this feature yesterday, so go with what’s quickest :wink:
  2. We have multiple clients and servers managed through a single instance of OttoDeploy so that it’s centralise and easy to find. For this reason I think we’d prefer greater visibility rather than less.
  3. Preference would be a stored deployment, I can imagine wanting to deactivate the schedule and then reactivate it without having to recreate it.

I’ll point my colleagues to this post to see if they have other perspectives.

1 Like

I agree with all of @sam_teamDF’s responses.

  1. Definitely OttoDeploy for the same reasons - keep it all centralised in one place
  2. Yes I like this idea of being able to see these in OttoFMS Console. Being able to pause/suspend them temporarily from here would be idea, but again this should still ultimately be able to be achieved via OttoDeploy too for a single source of management.
  3. Stored definitely. I would imagine it working in a similar fashion to the FMS Admin Consoles scheduled script or backup configuration where you specify frequency period every X hours/days between a start/stop (or indefinitely).

I would add to this also a point about notifications. This might be something already achievable, but I did not see this in the OttoDeploy configuration. Is there any way to have an error (or success) email sent post deployments ? This could just be a general option to email the log of any deployment to a nominated email address. For standard deployments this is less important but for a scheduled deployment (especially overnight or recurring) I can see value in this so the developer does not need to keep checking the console or OttoDeploy to see whether everything worked.

That is obviously a lower priority request than the recurring functionality, just adding it in here as an idea really.

Hey y’all,

I’ll be working in recurring deployments in the coming weeks thank you for all of your ideas! If the only thing you’re worried about is being able to pause and start the schedule rather than edit the details of the deployment, we probably won’t need a separate deployment system, you’ll be able to edit the system script as you see fit.

My current working idea is that when you set up a scheduled deployment it will ask you for a time to run, and wen you submit it will create a schedule. You would be able to go into the FileMaker Admin Console and update that schedule from a Once type to a Once every X days or a Weekly type. Then, when the deployment runs, OttoFMS will check on the type of schedule that you have entered and will schedule a new deployment and update your schedule with the new deployment id. This way you would be able to change the FMS schedule however you like and it should work with OttoFMS without too many changes and too many new structures to support it.

I’ll have to build in a couple of extra features around this (ie. deleting the schedule from the OttoFMS console somewhere), but otherwise I could see this working great. I appreciate all the feedback!

@weetbicks currently OttoFMS does not support email notifications, although it is on our roadmap to get working. OttoFMS does support Slack notifications for deployments, this functionality was added in version 4.3.0. We have not released a new version of OttoDeploy that supports adding these notifications for your deployment, but you can add it manually. Check out the docs for some more details on setting that up.

For the email notifications, would you want it to be the same emails we’ve been playing around with a couple of ideas. One is to use the same email notifications that you can set up in FileMaker and essentially piggyback off of that configuration. The other would be to have y’all enter just any email you want to send notifications to. Is the email notification something you’d want to configure separately?

-Kyle

1 Like

Thanks @kduval ! I didn’t realise it supported Slack, that’s actually better for me than email so it’s perfect, I’ll look into setting this up !

1 Like

Perfect! We’re going to be releasing a new version of OttoDeploy that makes the Slack integration much easier later this week or early next week. Let me know if there are any issues!

-Kyle

Hey @kduval/
How about supporting cURL based notifications?
I use both Prowl and Pushover which just require a single url with inline parameters…

Hey John,

Thats an interesting idea. we talked about curl or webhook based notifications, that could certainly be possible. I’ll add it to our list! We would pass the sub-deployment id, a url to go to the sub-deployment, and a status message probably.

Thanks!

-Kyle

I tried with Otto3 to make the webhook work with Connect, but the payload was not arriving correctly, thought it might be time to look again at that. Will DM you an example…

1 Like

Your approach sounds like a good plan. I’m looking forward to it. Thanks @kduval!