Create a Java project release pipeline for continuous deployment with Azure DevOps Services

  • Article

TFS 2018 | TFS 2017

In this exercise, you are going to create a release pipeline that will start the container images from the build lab. You will then create an Azure Container Service (ACS) and modify the Release to start containers in ACS.

Note

These Hands-On Labs use a virtual machine with a Java environment configured by our partner, Northwest Cadence.

Learn how to connect to the Java VM environment here.

Prerequisites

This exercise assumes you have completed the exercises to create a Team Project and have set up the Docker private Azure DevOps Services agent. You should also have set up Maven package management and have a MyShuttleCalc package in the feed and created a build that creates and publishes Docker images to the Azure Container Registry. This exercise uses a team project named jdev, though your team project name may differ.

Install a Marketplace Extension

In this task you will install an Azure DevOps Services extension from the Azure DevOps Services Marketplace. This extension contains build and release tasks - you are going to use the ReplaceTokens task in the Release.

  1. Connect to the virtual machine with the user credentials which you specified when creating the VM in Azure.

  2. Open Chrome and browse to http://<youraccount>.visualstudio.com (where youraccount is the account you created in Azure DevOps Services).

  3. Click on the shopping bag icon on the upper right and select "Browse Marketplace".

    Navigate to the marketplace

  4. In the search toolbar, type "replacement" and press enter. You should see "Colin's ALM Corner Build & Release Tools" in the results.

    Search for replacement

  5. Click on "Colin's ALM Corner Build & Release Tools". Then click on the Install button.

    Install the extension

  6. In the dialog that appears, ensure that your organization is selected and click Continue. Once your permissions have been verified, click the Confirm button.

Create a Release Pipeline

In this task you will create a release pipeline with a single stage called AzureVM. You will configure the release to run the MyShuttle application containers (one is a mysql container with the database and the second is a tomcat container running the MyShuttle war). You will also add an integration test run that will ensure that the app is working correctly.

  1. Connect to the virtual machine with the user credentials which you specified when creating the VM in Azure.

  2. Open Chrome and browse to http://<youraccount>.visualstudio.com (where youraccount is the account you created in Azure DevOps Services).

  3. Click on the jdev team project to navigate to it.

  4. Under the "Build and Releases" hub, click on "Releases" and click the button in the page to create a new release pipeline.

    Go to the Releases tab

  5. In the template flyout (on the right side), select an empty process as the template for the release pipeline.

    Select empty process

  6. Click on Stage1 to open the properties flyout. Change the name to "AzureVM".

    Rename Stage1

  7. In the "Artifacts" component of the release pipeline, click on the "Add artifact" button to add a build pipeline as an artifact source to the release pipeline.

    Add artifact

  8. In the Artifacts flyout, choose the MyShuttle2 build pipeline as the artifact, keep the default version as latest and the default value of the source alias. Then press the "Add" button.

    Add MyShuttle2 artifact

  9. Click in the name of the release pipeline and rename it.

    Rename release pipeline

  10. Click on the trigger icon on the Build Artifact. In the property flyout, ensure that the Continuous Deployment trigger is enabled. Set the branch filter to main so that only builds from the main branch trigger the deployment automatically.

    Continuous Deployment trigger

  11. Click the link labelled "1 job(s), 0 task(s)" in the AzureVM stage card to open the jobs/tasks editor for the stage.

  12. Click on the "Agent Job" row and change the Queue to "default" so that your self-hosted agent executes the release tasks for this job of the release.

    Edit the job settings

  13. Click the "+" icon on the job to add a new task. Type "replace" in the search box. Add a "Replace Tokens" task.

  14. Set the following properties for the Replace Tokens task:

    Parameter Value Notes
    Source Path $(System.DefaultWorkingDirectory)/MyShuttle2/drop The path in which to search for tokenized files
    Target File Pattern *.release.* The file pattern to use to find tokenized files in the Source Path

    Replace Tokens task

    Note

    There are 2 tokenized files that the release will take advantage of, both of which live in the root of the MyShuttle2 repo. The build process published these files so that they are available as outputs of the build, ready for use in the Release process. docker-compose.release.yml contains tokens for the host port, container image names and tags. testng.release.xml contains tokens for the baseUrl to test. These tokenized files make it possible to "Build Once, Deploy Many Times" since they separate the stage configuration and the binaries from the build. The Replace Tokens task inject release variables (which you will define shortly) into the tokens in the files.

  15. Click the "+" icon on the job to add a new task. Type "docker" in the search box. Add a "Docker Compose" task.

  16. Set the following properties for the Docker Compose task:

    Parameter Value Notes
    Container Registry Type Azure Container Registry The release will get images from an Azure Container Registry
    Azure subscription <your sub> The subscription with your Azure Container Registry
    Azure Container Registry <your acr> The container registry you created in a previous lab
    Docker compose file $(System.DefaultWorkingDirectory)/MyShuttle2/drop/docker-compose.release.yml The compose file to use for the release
    Action Run service images Sets the action to perform (in this case an up command)
    Build Images Unchecked Use the images that were built in the build process

    Run Services task

    Note

    This task will start the 2 container apps in the docker engine of the host VM.

  17. Click the "+" icon on the job to add a new task. Type "command" in the search box. Add a "Command Line" task.

  18. Set the following properties for the Command Line task:

    Parameter Value Notes
    Tool java Invoke java
    Arguments -cp myshuttledev-tests.jar:test-jars/* org.testng.TestNG ../testng.release.xml Arguments for the java command to invoke the integration tests
    Advanced/Working folder $(System.DefaultWorkingDirectory)/MyShuttle2/drop/target Run the command in the correct folder

    Run Java task

    Note

    This command invokes Java to run testNG tests. The run uses the testng.release.xml file which at this point in the release contains the correct baseUrl for the tests. If the tests fail, the release will fail.

  19. Click the "+" icon on the job to add a new task. Type "publish test" in the search box. Add a "Publish Test Results" task.

  20. Set the following properties for the Publish Test Results task:

    Parameter Value Notes
    Test results files **/TEST-*.xml Invoke java
    Control Options/Continue on error Checked Uploads the results even if the tests from the previous step fail.

    Publish Test Results task

    Note

    This command grabs the JUnit test results file from the test run and publishes them to the release so that the test results are available in the Release summary.

  21. You should have 4 tasks in this order:

    Tasks for the Release

  22. Click on the Variables tab. Enter the following variables and scopes:

    Name Value Scope Notes
    baseUrl http://10.0.0.4:8081/myshuttledev AzureVM BaseUrl for test run
    DbImageName <your azure container reg>/db Release Image name of the database container
    WebImageName <your azure container reg>/web Release Image name of the web container
    HostPort 8081 AzureVM The port to expose the web app to on the host
    Tag $(Build.BuildNumber) Release The tag to use for the container images - tied to the build number.

    Variables for the release

    Note

    You will need to use your azure container registry (e.g. cdjavadev.azurecr.io) in the image variables. Instead of using the :latest tag for the images, we explicitly use the build number, which was used to tag the images during the build. This allows us to "roll-forward" to previous tags for the images if we want to revert a release. The scope setting allows us to make variables that live at a release level (Release) or are stage-specific (like AzureVM). If you clone the stage to repeat this release in additional stages, you can just specify new values for the variables for those stages.

  23. Click the Save button in the toolbar to save the pipeline.

  24. Click the "+ Release" button and then click Create Release.

    Create a new Release

  25. Click the queue button on the Create a new release dialog to start the release.

    Click the release number

  26. Click on Logs to view the logs from the release.

    Click Logs

  27. When the release completes, click on the Tests tab and then change the filter to see that the tests all succeeded.

    View test results

  28. In Chrome, browse to https://localhost:8081/myshuttledev/ to see the site running.

    The site is running

    Note

    You can log in by entering username fred and password fredpassword.