Hey J,
We are planning on doing this, it has been pushed down the priority list as we work on other things for a bit. I will say that it is the next big feature we are planning on putting into OttoDeploy, but that the OttoFMS API fully supports this at the moment.
Setting up a deployment to multiple servers is simply sending a deployment to each server individually at the same time, but you have to use a build that you have made ahead of time so that you are not running just in time builds at the same time. It should be relatively simple to set up a script that will kick off a set of deployments to all of your servers that works with OttoFMS, I’ll detail the steps this script would need to take below. The only thing that we are going to do in OttoDeploy is apply some UI on top of the already existing OttoFMS APIs so that you have an easier way to set up the deployments than managing the JSON yourself.
For setting up a multi-server deployment in OttoFS as we are now you need a list of the servers you are deploying to (if filenames are different on each server you’ll need some sort of data that you can use for mapping the file names from your source server to each of the development servers), the details of your source server, and the JSON for starting your build and sending your deployments. You could run the build ahead of time or tie it into your script and poll the result of the build before sending off your deployments.
You’ll need to manage the flow of a build running before your deployments, which you can do manually, with your script, or by using the chainedAction option in the OttoFMS build API. I’d recommend the chainedAction option, it will make your script easier (although it will make your JSON horribly complex). You’ll then essentially need to run the build, then kick off all of your deployments with the build you’ve run as the source. All of the deployments can run in parallel since they’re on different destination servers, and they will all grab the same source files from the build you’ve already run.
I could definitely see a world where you have a set files, a list of destination servers, and the source server info that could generate the proper JSON to kick off all of these deployments pretty easily, but I also am doing essentially that every day for the OttoFMS testing, so I probably have a skewed sense of how easy it is to manage the JSON objects in question (spoiler they’re gnarly).
Example psuedo-code (this syntax is weird but you get it)
sourceServer = {url:https://kyle.ottomatic.cloud, apiKey:key123}
sourceFiles = ["test.fmp12","testUI.fmp12"]
destServers = [{url:https://kyle1.ottomatic.cloud, apiKey:key123},
{url:https://kyle2.ottomatic.cloud, apiKey:key123},
{url:https://kyle3.ottomatic.cloud, apiKey:key123}]
buildJSON = {
files: [
...]}
buildOptions:{...}}
Run the build here with the api (or skip it here and use the chainedAction)
deploymentJSON = {
source:{
type:"ottofms"
buildID:"build-id"
url:sourceServer.url
apiKey : sourceServer.apiKey}
files:[...all the files you want to send and their operations]
...all the other options you want (maybe some slack notifications??)
}
for (server of destServers) {
Kick off each deployment (if you're doing a chainedAction, create the JSON for each deployment, then add them to the chained action information on the build JSON)
}
Done (unless you want to poll the statuses or something, you could just get Slack notifications when they're done instead if that works)
All that said, we are planning on adding this to OttoDeploy (and probably the Cloud Console) at some point, but that timeline is in flux as we work with changing priorities. I’ll keep y’all updated on the progress on it as we go!
-Kyle
Edit: that was longer than I thought it would be. tldr: we’re going to get to it at some point, if its blocking you its probably not as hard as you think it is to write it yourself as the functionality already exists, we just need some UI for it (and lets be honest sometimes you don’t need the UI to get things done, especially for people as smart as y’all)