We release once a week on a schedule. Every week we deploy 1 or more projects from our 2020.1 Octopus server. Not all projects see a release every week. In most cases there’s a required order in which we have to deploy all the projects.
Based on research and experience, I know I can utilize the community step to chain deploy to set each release. The issue I have with this approach is I’d have to add a step for every single project, and each week modify the release cycle to re-order or skip the steps with projects not being deployed. Since there’s over 15 projects, I don’t see this as a viable option.
I know how triggers work, and assuming we deployed all our apps in an afternoon, I could generally approximate how long each deploy takes and write a schedule for them. The concern I see here though is that I would still have weeks where the deploy is not “full” aka all of the apps, and there would be huge amounts of time wasted waiting for various apps to deploy. This is especially noticeable when the apps with 10+ deploy targets aren’t getting a release and something would be scheduled to run immediately after that.
Best example that I can give of the above is that there’s projects A through H, they take 5 minutes each to deploy. Week 1, I deploy all the Apps. Week 2 I don’t need to deploy B,C,D, but deploy A,E,F,G,H. I’d be waiting 15 minutes for things to happen when I could get them all taken care of immediately and shorten the deploy window, thus giving my teammates more time in a day to react quicker if there’s a problem.
What are my options for trying to make such a task work?
There is a built-in Deploy Release step, which like the chain deploy community step triggers the deployment of other projects, but also has the option of specifying that deployment should not occur if the release being deployed is the current release in the environment.
This allows you to create a “bundle” project which contains steps for all your projects, but only those projects which have new releases available are actually deployed.
Do you think this would achieve your goal?
Somehow you have to tell Octopus which projects should be deployed. In the approach above, it is the availability of a new release. Another approach I have seen is:
Create a bundle approach (as in the approach above), but include a “manifest” of the projects which should be deployed. This may be a JSON file embedded in a package, or a step can make a HTTP/database call to retrieve the manifest, etc. The first step of the bundle projects deployment process reads the manifest and sets a bunch of output variables, which each following step uses as run conditions to decide whether they should execute.
I’m going to have to investigate the bundled approach with a manifest. I like the deploy release step approach, however i’d still have to re-arrange the steps each release whenever there’s a dependency that changes the natural order we deploy. ’
can you go into more detail on the second approach?