Adjust the deployment process to check for the availability of the manifest.json before closing the source files, to ensure faster failure and reduced resource consumption.
Current Process:
Close all source files.
Attempt to download the manifest.json.
If the download fails, reopen the databases.
Proposed Process:
Attempt to download the manifest.json.
If the download is successful, proceed with closing the source files.
Continue with the deployment.
Background:
We set up an automated deployment every night a 2:00 a.m. that uses a source url for the build. When we deploy, we simply upload the files to the given location and the deployment will start automatically. Otto first closes all source files and then tries to download the manifest.json, fails if the files are not available and opens the databases again.
If I understand you correctly, you can already do this.
There is an option on the deployment called closeFilesAfterBuild. It’s exposed as a deployment option in OttoDeploy.
If you set this to true, the files will be fetched to the server, before the files are closed. If it fails to download the files the files will never get closed
This would result in a “Fetch failed error”. Which isn’t ideal. But it would do what you want.
Stay tuned for some new features which might give you news way to do this sort of thing without the Fetch failed error.
Would be nice for scheduled deployments if you could set it to download/JIT the build at time X and start deployment in time y. And if download fails notify and stop the deployment.
That way we could let it download the build in the afternoon after office hours and start the deployment at the desired time. And if the download fails try to fix it before the deployment time
We are also working on a way to Build the files, send them to the Production server, so they are there just waiting. Then when the deployment gets triggered the files are already there.
The “Publish Build” option in OttoFMS version 4.5.0 and OttoDeploy 1.2.6 allows you to run a build and push it to your destination servers inbox. When you run the deployment it will simply grab the build from the inbox and use it for the deployment. This makes the fetch process instantaneous and lets you run the builds and fetching ahead of time.