I have a Project Group name Micro-services which contains about 35-40 small projects for each Micro Service. We did that to accomplish different life cycle to each Micro Service, and to be able to trigger deploy from TFS once it complete the build to the TEST env. (Hope Its best practice )
So, lets suppose that I would like to deploy Projects No. 2,5,10-14, It sure can be done by click each project and deploy one by one , But I’m looking for the easy way: to group each time the relevant projects together and to click once for deployment, I would like to keep the life cycle of each one, Basically it’s promote from TEST to PRE and then then to PROD.
Thanks for getting in touch! It looks like you may benefit from our Deploy Release Step. This step is fairly self explanatory, it lets you deploy a release for a project. You can add multiple deploy release steps to a single project.
Many thanks for your quick response.
The release step is partly answer our objective, it need to be manually. Each version we will deploy different projects, and it can be once 2 projects and other 10 or 12 projects.
I am looking for something more automated, or to mark the relevant projects which need to be deploy to the next version.
By the way, is that best practice to create to each micro service a separate project?
Thanks for getting back! First off, creating a project for each micro service is currently the recommended approach here.
As for making the deploy release project more manual, the first and most simplistic option would be that Octopus has the ability to skip steps each deployment.
Our documentation on deploying releases has a section on excluding steps from a release. This approach means you would create the release for your deploy release project and manually decide which steps are run at the time of deployment. This would give you the option at each run of the deploy release project to decide exactly which parts you would like to deploy.
Is this a reasonable solution to your issue?
If not, you may be able to streamline your deployments with optional Lifecycles. However, if the above excluding steps idea does not help, I will need some more detailed information about your current Lifecycles to get a better idea of what could be changed to help.
Please feel free to let me know if you have any questions at all here.
)