Is there a way to use powershell to change the package configured in a step of a project?
Example:
we have 4 development lanes (A,B,C, and D) Each of those Lanes may get re-purposed every 2 weeks for a different development focus. if the if the Music app is developed in LaneA A it is packaged up and sent to Octopus as MusicAppA. If it is developed in LaneB it is packaged up and sent to Octopus as MusicAppB. As the final deployment step in each lane after the package has gone through testing, I would like to have a step that updates the Production deploy job to use that package. The reason being, I want one place to go and see what was last deployed to the production Music app, rather than having to check 4 different Music lane projects to see which one last deployed to Prod.
a Production deploy project has a step to deploy MusicPackage to a directory on a production web server.
For your development lanes, are you using 4 different development project, one development project with different channels, or another configuration?
If I’m understanding the process correctly, I would suggest changing the package naming scheme slightly. Instead of putting A, B, C, or D in the package name, I would move that to the version as a prerelease tag.
For example, if it is in Lane A, the full package name with version would be something like MusicApp.1.2.3-A or MusicApp.1.2.3-DevA.
Every project and step would reference the same package id but you would choose the version based on the lane when you create the release.
If you are using separate projects or channels, you can use package version rules so that they are limited to versions with the prerelease package that matches their lane, but the production project can use any version.
If making this change is not possible for you, you can use the Octopus API to fetch the deployment process of the production project and change the package ID. Here’s an example to get you started. Instead of changing the Channels property, you would access the Packages collection and set the PackageId on the target package.
The first solution will be the best in the long run, and depending on your current process and set up, it could be possible to set up a single project for dev and production deployments so that you can promote directly from a dev lane to production.
Sorry for the slow reply, I was out for a bit.
4 different development projects. If I understand your suggestion correctly, then by telling the production job it can use any of them, would the production job just grab whichever package is the latest regardless of which lane its in? That would take a bit of rework but might be the best way. I’ll also take a look at the API example. Thank you.
Another method I thought of doing is to export the production job, then upload it’s json file as a package and deploy it someplace so that I can use the json replacement feature to change the package configured, and then try re-importing it to update the prod job with that change. But to be honest that feels like the wrong solution, so I appreciate the suggestions.
So I tested what you were suggesting with moving the Lane Deliniator into the version metadata. That works. I had a hard time wrapping my head around that concept until you layed it out for me. So Thank you. I’ll go that route, thanks for helping me find the better way.