Single File to Multiple Server Deployment in OttoDeploy

twosouthpaws · February 19, 2024, 11:40pm

We have two service files that are independently deployed to 14 servers. With Otto this was very easy as a single file Migration could target multiple servers.

I spent the whole day re-entering all of the my deployments into OttoDeploy. (Please don’t to that to us in future updates. Ugh.) I don’t see where I can define a Deployment of a single file to update multiple servers. (Renaming not necessary.)

Am I missing something?

Jeff

kduval · February 20, 2024, 12:33am

Hello Jeff,

Currently OttoDeploy does not support sending deployments to multiple servers at once. That feature is essentially the first item on our roadmap right now, we’re deep in design discussions on how to set up deployment groups with the new system. We’ll keep y’all updated on the progress for this feature, but your situation is exactly the one that we’re targeting.

Sorry that we haven’t put that feature in yet, we’re working on making it better than ever!

-Kyle

toddgeist · February 20, 2024, 12:47am

Hi Jeff,

OttoDeploy has a built in updater. Based of course on OttoFMS. So it will always be able to upgrade itself. You shouldn’t have to redo your deployments again. Sorry about that. This was a FileMaker 6 to 7 situation.

We should have the non renaming deployment groups ( multi-server ) ready very soon.

Todd

twosouthpaws · February 20, 2024, 2:51pm

Thanks. I thought I was just tired. If you’d like to discuss the workflow options, let me know.

Consider the use case of a single file failure within a sub-deployment. There is an option “Abort remaining on failure”. This implies that if you had 25 file set defined and one failed, the remainder will be deployed. If the option is enabled, I assume the entire deployment will rollback (Atomic).

Consider the example above with the toggle off. If one of the sub-deployment failed and the rest were able to complete, how would your re-run the one failed sub-deployment?

One nice feature of ClarisConnect is when a workflow fails to complete, you can login and rerun the one flow without having to resubmit the initial call.

It would be nice to be able to run one or a selected group of a sub-deployment. (This is related to another topic I will begin. “File deselect within multi-file Deployment”)

Jeff

kduval · February 20, 2024, 3:06pm

Hey Jeff,

With sub-deployments and the abort remaining option we do not roll back the entire deployment if a single sub-deployment fails, we just do not do the remaining sub-deployments (since they are performed one after another). Each sub-deployment is atomic, the deployment as a whole is not necessarily atomic when using sub-deployments.

The abort remaining option is primarily intended to be used with deployments that perform multiple actions on a file. If I am doing a staging refresh I do not want to migrate my schema from dev if my copy down from production fails.

For the case of a deployment to multiple servers we are likely going to be moving outside of the deployment/sub-deployment paradigm slightly (or at least expanding upon it) since you may want to run a deployment with sub-deployments on multiple servers.

Thanks!

-Kyle

twosouthpaws · February 20, 2024, 8:55pm

Hi Kyle,

I know I have a different use case than may have originally planned. But consider the following:

I am hosting 25 copies of the same file set. (25 difference agencies) Each has a unique name.
If one deployment fail, say number 12, and the reset complete.
How would I reinitiate the deployment for agency 12?

Previously, I would have deselected the other files in the migration and only have the files for agency 12 enabled.

I don’t see that as an option at the moment.

Jeff

kduval · February 20, 2024, 9:58pm

Hi jeff,

Are all of these filesets on the same destination server? Right now there is not a way to rerun that single sub-deployment. We’re planning on putting together the ability to rerun a sing sub-deployment (and a whole deployment) from the OttoFMS UI, but the functionality does not currently exist.

It sounds like you’re also talking about the ability to essentially choose which parts of a deployment happen from OttoDeploy, which is an interesting idea. I think we could work something out for that, I can add it to our list.

Thanks Jeff!

-Kyle

toddgeist · February 20, 2024, 11:20pm

This is a really good use case, and one I think we can add pretty quickly.

Thanks for bringing this one up.

Todd

twosouthpaws · February 20, 2024, 11:21pm

Hi Kyle,

Yes, all of these files are on the same server. The reside in folders named for he agency IDs. Each UI, DATA and DOC file includes the agency ID.

Here are a couple of screenshots:
UI Folder

Data/Doc Folder for one agency:

As for the selection of part of a deployment, the other topic addresses that need.

In this case, I am just wondering how you envision re-running part of a deployment that had failed. If I had 25 sub deployments defined and one failed while the rest completed correctly, I’d like to only re-run the failed deployment rather than the whole job or be required to define a new one off deployment.

Does that make sense?

Jeff

toddgeist · February 21, 2024, 12:07am

I think we can do it in a couple of different ways.

In OttoDeploy, we could give you check box that says on the Sub-deployments that says something like “Run Only this one”. So you would go back to OttoDeploy fix what you need to fix and then check the “Run Only” box on the sub deployment you wanted to run and and then Start the deployment.

After the Deployment starts we could clear the checkbox or not.

If the sub-deployment failed for a reason that had nothing to do with how it was setup, like if somebody refused to get out of a file and caused the deployment to fail to close all the files, then we could give you button in OttoFMS, on the sub deployment that failed that says “Try again” or re-run.

What do you think about these ideas?

Thanks

Todd

twosouthpaws · February 21, 2024, 12:23am

I don’t know that you need to clear the checkbox. A status on the sub-deployment could be enough: Queued, Compete, Error.

Then, a button on each sub-deployment to run only that one would be helpful. It could be run again regardless of status.

Clearing the checkbox might be confusing when you run the whole deployment again.

Jeff

toddgeist · February 21, 2024, 12:29am

Thats good feedback. We’ll likely break it up into two features in OttoDeploy

A button to run any sub-deployment by itself.
A status view (queued, complete, error ) of the last time you ran the deployment.

Number 1 is relatively easy, I don’t want to wait for number 2 to ship it.
Number 2 has more moving parts, so it is going to take a little longer.

Thanks

Todd

twosouthpaws · February 21, 2024, 12:33am

Number 2 - at least the error status is necessary, otherwise how would you know it need to run again.

Jeff

toddgeist · February 21, 2024, 12:48am

Not saying we won’t do 2. Just that 1 is easy and useful on it’s own and we can do it right away.

2 will just take more time. I don’t mean months, I mean weeks.

All of that information, including which ones failed is visible through OttoFMS. You can see the status of every deployment and sub deployment. So you could see which ones failed there. That is currently the only place you can see the status of a deployment. That isn’t the way it will be for long… but it is right now.

So you could see which sub-deployment failed on OttoFMS and re-run it with OttoDeploy. Very clearly that isn’t ideal. We aren’t talking about this being the feature for ever. We are talking about taking steps to get there.

Shipping small changes as often as we can whenever we can is always going to be how we do this.

Hope this helps explain our approach

Thanks

Todd