You may be using Octopus deploy for your deployment automation pipeline needs while you are having your builds and work items managed in VSTS. It is a good idea to manage the Octopus release pipeline via VSTS release management so that you have the opportunity to use automated test execution and capturing of test results, as well as easily generate release notes using the VSTS work items, using feature rich tasks and automation test results views in VSTS release management. Let’s look at the important steps required to make VSTS release management to successfully utilize your existing Octopus deploy process steps.
The first step is to make all the lifecycle except first one optional in Octopus, so as to allow VSTS release management to decide when to trigger a given environment in a phase. Make sure to add phases and make the phase optional even if a phase contains a single environment as shown below. This is mandatory to allow VSTS release management to control the process flow of deployment pipeline.
As the next step you need the connectivity from VSTS and its deployment agents to the octopus server. To add Octopus as a service for VSTS you need to create API Key in Octopus. Go to you profile in Octopus.
Click on create New API Key.
Provide a name (purpose) for the key and click on Generate Key.
Make sure to copy and keep the API Key in a safe location as it will be required to configure VSTS service endpoint for Octopus.
In the VSTS team project go to Project Settings => Service Endpoints and click on New Service Endpoint to select Octopus Deploy endpoint.
Provide the octopus server URL and the API Key from octopus along with a friendly name for the service endpoint.
In your build you can push your packages to Octopus server or push them to VSTS Package Management feed and let Octopus utilize packages from VSTS Feed as explained in post “Integrating VSTS Package Feed to Octopus”. Make sure to version the package with the build number, as this would be used in release management steps to let octopus know the correct package version that needs to be deployed.
To create release and trigger a deployment from VSTS you can use the tasks comes with Octopus extension available in marketplace. These are same tasks that can be used in VSTS build for triggering a deployment in Octopus. However, the difference here is instead of letting Octopus controlling the flow of release through the pipeline, VSTS release management pipeline will control the flow. As explained above Octopus environments should be setup as deployment optional to enable this control from VSTS side. The VSTS pipeline should be setup to create the octopus release in the first environment. From the second environment onwards it will only be deploy octopus release task to trigger the deployment in different environments defined in octopus.
You should connect the build which is pushing the NuGet packages to octopus, or VSTS Package Management feed to the release definition. Since the build does not have published artifacts drop, there will be a warning saying no artifacts in the latest version. This can be ignored safely.
In the agent phase of VSTS make sure to set not to download any artifacts as it is not required, since Octopus is doing the deployment.
In the first environment of the release pipeline in VSTS you should have the create octopus release task, which will trigger a deployment to the initial environment. If you have setup in Octopus to not to trigger a deployment once release created you can add a second task to trigger deployment which will be explained next. In the create Octopus release task, make sure to provide the VSTS release name, variable as the release number, so that it can be used in subsequent deployment trigger tasks to locate the correct release created in Octopus. Select the Octopus service endpoint created earlier and select the Octopus project defined. It is not required to define the channel but even if it is defined no harm as long as you select the correct channel in octopus and the environments planned to control deployments with VSTS release management is included in that channel.
Then make sure to define the Tenant if you have configured a Tenant based deployments for the Octopus project. The most important setting is providing the build number as the package version. you can do this by providing additional argument to octo.exe as --packageVersion $(Build.BuildNumber) . This will make the Octopus release to be created with the package version of build number. Select the first environment defined in Octopus as the environment to be deployed, and make sure to check the Show deployment progress, which enforces VSTS Release Management to wait for the Octopus release to complete deployment to target.
In the second or any subsequent environment in VSTS release pipeline you just have to define a task to trigger deployment in Octopus release already created. For example next environment DEV setup in Octopus, as we described earlier earlier can be setup to deploy with the next environment in VSTS Release pipeline.
Make sure to NOT to provide the package version in these subsequent deployment task as it would throw an error to VSTS release management from Octopus saying “Unrecognized command arguments: --packageVersion, 1.0.6”, as for deploy command package version cannot be provided as an argument.
With this setup you can control the deployment from VSTS and the octopus deployments will be triggered, as you approve the VSTS release management pipeline environment for deployment. The advantage of this approach is you can utilize your existing Octopus deployments for your deployment purposes, while leveraging ability of VSTS to provide enhanced capabilities of test automation integration, reporting of test automation results as well as seamless integration of release notes with VSTS work items and other rich set of capabilities to integrate with many other services.
No comments:
Post a Comment