Along with being able to push a “release” to multiple servers… which would be huge…
It would also be interesting if we could have multiple privileges where we could say that a developer (Me) could create the build and push out a release. But also to have another privilege set that would only allow a group to only be able to push the release out but not be able to create the release.
The advantage to this is that our releases are done by our India team and having something simple they could do would make life a little easier for us as well as them.
This is an interesting idea. I can see how this would be nice. It might be something that is tied into something we’re working on in the Ottomatic Cloud Console, which is intended to work with the entire development and release process.
I could see a world where you are doing development and creating releases, then you have a group who can take those releases and run the deployments to destination servers for it. It would be a simple case of a set of users in the cloud console and then settings on the project to decide who can do what actions.
The way sub-deployments work make it so that there is no way to have sub-deployments in a single deployment running on different servers. The deployment itself is running on a single server, so there is no way to have its sub-deployments running elsewhere (at least not without changing the entire deployment paradigm).
However, that being said, we’re going to have the option to run the deployments in parallel or in series. Deployments running in series does essentially the same thing that running sub-deployments does, where it runs them one after another. Unless you have something specific you need sub-deployments in a single deployment for, this should get you what you need. Running deployments on different servers in series is also currently supported in the OttoFMS API using chained actions, we are simply going to provide a UI for it in OttoDeploy.