I suggest you...

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).

241 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    under review  ·  Octopus DeveloperAdminOctopus Developer (Admin, Octopus Deploy) responded  · 

    Hi everyone

    Thanks for supporting this idea. We’ve had some discussions around this internally, and while we like the concept, it is significantly more complicated than it appears on the surface.

    For example, what would happen if the environment changes between deployment of a dependent project and the point where the project that depends on it is deployed? Another edge case is around dealing with failed & partial deployments. There are many more edge cases here as well.

    We are hesitant to implement a feature when there are so many situations where it may not work as expected.

    It would be very helpful if we could have some specific, detailed scenarios where this functionality would be helpful. Once we have these, we can re-evaluate again.

    Thanks in advance,
    Matt

    12 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • AdamAdam commented  ·   ·  Flag as inappropriate

        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 CORNELYArnaud CORNELY commented  ·   ·  Flag as inappropriate

        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 SchultzJim Schultz commented  ·   ·  Flag as inappropriate

        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.

      • Chris CamburnChris Camburn commented  ·   ·  Flag as inappropriate

        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.

      • Chris CamburnChris Camburn commented  ·   ·  Flag as inappropriate

        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 WittPaul Witt commented  ·   ·  Flag as inappropriate

        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?

      • rstraszewskirstraszewski commented  ·   ·  Flag as inappropriate

        Awesome idea, we have tons of microservices, and it would be great to finally be able to manage dependencies between them.

      • Darren LiddellDarren Liddell commented  ·   ·  Flag as inappropriate

        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

      • JoeJoe commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base