Advice on automated releases based on new commits in a branch

[ryan.holmes]

I apologize - I can’t seem to open a new post on the Advice forum, so I’m posting here. I hope maybe one of the moderators can move it to the proper location?

Here’s the tl;ldr version: How can our build server (Jenkins) send the package with the same ID to octopus, but mark it for release to another environment? We wish to use this so that we can build both development branches and master branches, and have them automatically deploy to the Dev and Staging environments, respectively, using the same project in Jenkins and Octopus Deploy.

But really, it might be best for me to explain our current workflow, and hopefully get some advice on how to best transition this into Octopus Deploy.

We currently have a web project that we host internally for our company. We use a modified gitflow workflow:

• Feature branches that are created for any feature / bug / changes that needs to occur.
• Development branch. Feature branches get merged into development, which is then built and deployed to our Development environment. This is used for testing the PR.
• Once a PR is approved, the feature branch is merged into master, and this automatically gets built and deployed to our Staging environment. At this point, staging should be the approved bug fixes and features for the next release.
• When we want to deploy a release, we merge master into a release branch
• One thing to note: our development branch never gets merged into our master branch directly. Development branch is mostly for us to test the PRs without having to pull each branch down individually, and can include multiple in-flight features

As noted above, we have three environments: dev, staging, and production. Our build server (Jenkins) picks up on changes in our git repo for those three branches that correspond to their environments (respectively : development, master, and release). Unfortunately, we have three projects in Jenkins, one for each environment, so that we can do environment-specific transformations and deployments (this is what we’re hoping to change using Octopus Deploy). At the end of the build, Jenkins does the deployment to the environment via IIS Web Deploy.

We’re currently evaluating Octopus Deploy to take over the deployment of our packages, but there’s a few uncertainties as to how to properly integrate this with our git branching strategy (where commits to development go to Dev server and master goes to Staging, automatically). The step for production can simply be a manual promotion of what’s currently in staging, so we’re not worried about that at the moment.

We have a test project up and running where Jenkins takes the development branch, builds it, packages it using octo CLI, and pushes it to Octopus. Then we have Octopus configured to automatically deploy that package as a release to development as soon as the new package becomes available. But the main sticking point is we don’t quite know how to integrate our automated master branch build on the build server to deploy to staging (unless we give the package a different ID, but then we need basically a duplicate project in Octopus).

Thanks for your time and advice!

[phil.stephenson]

Hi Ryan,

Thanks for reaching out and thanks for your detailed explanation!

I think your workflow sounds completely reasonable and Octopus can absolutely support what you’re wanting to do. I’m sure it’s quite a pain managing 3 separate Jenkins projects just because it doesn’t model Environments well

It sounds like in your case you’re using the Octo CLI to push packages to Octopus, but have you tried the Octopus Deploy plugin for Jenkins? With the plugin you can create packages, push them to Octopus, create releases and even deploy releases. The Deploy Release feature even lets you select an environment to which you want to deploy. If you have 3 separate Jenkin’s projects corresponding to your branches, you could just hard code the corresponding environment there in your respective Jenkins builds. This is probably the easiest solution.

If you want to stick with the Octopus CLI, you can also use it to explicitly create and deploy a release with specify many different options (including Environment). Here is a reference to the deploy-release option with the Octopus CLI. This works a bit better in my opinion than trying to use the Automatic Release Creation feature because it gives you more control.

Lastly, Octopus also lets you create what are called Channels. These allow you define behavior that is a function of the version of your package. For example, if you were to be really strict and follow the semantic version rules, your “pre-release” versions of your software, the ones that you build based on your “release” branches could have a “-beta” or a “-prerelease” suffix. For example: 1.2.3-beta. Using a combination of Channels and Lifecycles, you could get Octopus to deploy to the correct environments depending on the version of your package. This would of course require some change to your Jenkins builds such that it attaches the proper tag suffix to the package versions, but it’s also a really nice way to know exactly where your packages came from and where they’re headed.

I hope this helps! If you have any others questions do feel free to respond back.

Thanks,

Phil