Allow project dependencies - so deploying one project would automatically deploy all dependent projects
We have many dependencies between our projects. So for example we have cross database dependencies which mean that a particular version of the database must be installed prior to another version. Similarly we have base services that are required by all others that must be installed first. There is currently no way of telling Octopus that one project depends upon another.
We could create one great big Octopus deployment with all the steps in it to deploy the TFS projects/libraries in the correct order. But this would be very complicated because of the large number of dependencies.
It would be great if it was possible to say Project z version a to b depends upon project y version x? So if the user attempts to deploy project z version a through to b without first deploying project y version x. Octopus would automatically deploy project y version x first. Similarly if project y version x itself depends upon another project /version that would be deployed before project y version x. Before a project/version is deployed the list of dependent project/versions that will be deployed could be shown. It would also be great to be able to view a diagram showing the dependency tree between projects.
Cannot find another idea on this forum which describes this so adding new suggestion (original question http://help.octopusdeploy.com/discussions/questions/5627).
This was shipped in Octopus version 2018.2: https://octopus.com/blog/deploy-release-step/deploy-release-step
This would be great for triggering a Website getting to a step and pausing and triggering another Project to Deploy and continuing after the DB is deployed.
The more I think about this, the more I think the only way to handle it via the UI would be to add a dependency to another project, and then at release creation time select a version of the dependent project just like you do nuget packages.
It could function identically to nuget packages; default to latest, a manual entry box, a search feature, etc. It would be nice to have it be considered a "step" in the deployment process as well, so that if multiple dependencies are added that need to be run in a particular order, we could handle it.
We have a crude ad-hoc version running using the API in a step. For us, the first iteration is just running all releases for 'dependencies' projects that had the same version number as the 'master' project. At deploy time, the step creates and kicks off deploys for 'dependencies' projects using all the same deploy settings (env, lifecycle, time, etc) as the master. Ex: create releases for the seven 'dependencies' projects that are being deployed this cycle with version X.X.X.X; create and deploy master project to TEST with version X.X.X.X on Tuesday at 9pm. Ours do use the same lifecycles (in fact most of the projects deployment steps are identical other than package name).
It would be nice to be able to choose versions of each of the 'dependencies' projects, but we haven't figured out the UI side of that yet. Since we have our projects set to not redeploy it would be a convenient way to ensure environments were on the same version without deploying things we don't need to deploy again.
Our main driving factor here is to keep visibility into which projects/version are deployed where in all the dashboards, but reduce the number of clicks the deployment user has for each environment (both setup and promotion)
Arnaud CORNELY commented
The problem with self-implemented feature is actually all the edge cases that the team has though about. Using custom scripts will either just ignore these or end-up on a huge mess of API calls to cover all situations while I expect that code running inside octopus will have faster and more access to internal information.
If not all cases can be supported, I suppose that a limited feature in the idea of the comment from Chris Camburn would be a great starting point.
Jim Schultz commented
We need this feature. Being able to define an ad hoc list of projects and the order in which they deploy would be huge! Let us worry about any deployment failures and call it a beta feature if need be.
In regards to the most update from Octopus, I think when adding a dependency, it would be fair to either a) require that the projects use the same lifecycle, or b) allow it to ignore missing environments. Either one would I think be fine.
I don't see partial deployments as a consideration at all. The built-in gating between phases of a lifecycle already ignore partial deployments, and Octopus has never made a distinction about such a thing.
It would be nice to declare a project dependency within the project, then, on creating a release, it allows you to select a version of the dependent project in exactly the same way you select nuget versions. When deploying, it will ensure the dependent project is deployed.
I agree wit Paul below. The issue we have isn't necessarily deploying one project from another; we already have a few master orchestration projects that do that. The issue we have is saying we need to, at release creation time, state that version 1.0 of projectX depends upon version 3.0 of projectY. This would need to be configured at release creation, and whenever deploying projectX it should first trigger a deployment of projectY.
Paul Witt commented
Having one project run another isn't the issue. Having one release of one project depend on a specific release of another project is. How does these guides help with that problem?
Awesome idea, we have tons of microservices, and it would be great to finally be able to manage dependencies between them.
Great idea! We need it ;)
Darren Liddell commented
I like the idea, I think nuget dependencies is too fine grain, having project dependencies makes sense for some of my scenarios, as a project may not deploy packages but just run powershell script (that depends on some component deployed by the dependent project).
I'd be less interested in automatic deployments of dependent projects, but more put a block on deploying project y if project x has not yet been deployed to the chosen target/environment/release
I love this idea but I do not think the dependencies should be managed in the NuGet packages. It would be better to be able to tie it to the release definitions.
Michael Ferioli commented
Love this idea but I think it's already captured here: https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6129859-use-nuget-dependencies-to-track-dependency-between