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!