Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create new step-type to Deploy an Octopus Release #4180

Closed
MJRichardson opened this issue Jan 18, 2018 · 8 comments

Comments

@MJRichardson
Copy link

commented Jan 18, 2018

One of our highest voted UserVoice items is to allow creating dependencies between Octopus projects.

We have decided to support this by creating a new step-type: Deploy Release.

This will allow you to add a step to your project (parent) in which you select a different project (child) in Octopus.

When creating a release of the parent project, you will be able to select the version of the child project which will be deployed when deploying the parent.

This will faciliate creating "bundle" projects, which are responsible for deploying multiple child projects, which will aid in progressing the child projects through the environments as a set.

The UI for the step will look something like:

deploy-release-step-edit

The nice thing about this approach is you can insert regular steps into your parent project. e.g. Notifying Slack, Manual Intervention, etc.

Deploying the parent will trigger a regular release of the child projects, so the dashboard will be correct.

@BissTalk

This comment has been minimized.

Copy link

commented Jan 18, 2018

Could there be a option to only deploy if the child project version is less than the target version?
Say I need my backend API to be a minimum of version 2.1 before I can deploy my front-end web app.

@MJRichardson

This comment has been minimized.

Copy link
Author

commented Jan 18, 2018

@BissTalk
We agree this could be useful. We have decided to add it. Thanks for the suggestion!

@dwoldo

This comment has been minimized.

Copy link

commented Jan 20, 2018

When deploying parent projects that orchestrate multiple child (microservice) projects and each one of those children need to know other sibling configuration values, can these be shared or injected between the siblings and the parent?

@MJRichardson

This comment has been minimized.

Copy link
Author

commented Jan 22, 2018

@dwoldo the only way to do this in the first cut will be using Library Variable Sets.

This is an interesting idea though. Would you be willing to share your scenario in more detail? We have been bouncing some ideas around, and we'd like to see if they would fit.

@MJRichardson

This comment has been minimized.

Copy link
Author

commented Jan 23, 2018

@dwoldo actually, we changed our mind and decided to implement this.

We added a Variables section where you can pass variable values into the triggered deployment.

We will also capture any output variables generated by a child deployment and make them available in the parent process (including passing them back into subsequent child deployments). The docs will hopefully make this clear, but a picture tells a 1000 words so...

deploy-release-step-variables

@dwoldo

This comment has been minimized.

Copy link

commented Jan 29, 2018

@MJRichardson this is exactly the challenge we were trying to solve. The great advantage for us are microservice deployments where configuration from each child is useful for others. A webservice endpoint, for example, would be useful for RPC requests amongst services.

@MJRichardson MJRichardson added this to the 2018.2.0 milestone Feb 6, 2018
@mcasperson mcasperson closed this Feb 7, 2018
@octoreleasebot

This comment has been minimized.

Copy link

commented Feb 8, 2018

Release Note: Added new step: Deploy a Release

@lock

This comment has been minimized.

Copy link

commented Nov 23, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.

@lock lock bot unassigned markryd Nov 23, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Nov 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.