Automate CI / CD for Java Applications with Microsoft Visual Studio Team Services
- Tutorial
Hello, Habr! At first glance, the title of this article may seem strange to you: Java and Visual Studio - what do they have in common? Why is there Visual Studio at all, when there are many other cool Java development tools: Eclipse, NetBeans, IntelliJ IDEA and others (we will not arrange a holivar). In fact, Visual Studio now is not just a development environment, but a whole family of products where the Visual Studio IDE is just one of the tools. Under the cut, we'll talk about Microsoft Visual Studio Team Services (VSTS).
Microsoft Visual Studio Team Services- This is a DevOps cloud platform that allows you to flexibly build DevOps processes for continuous integration, assembly and deployment (CI / CD). Of course, this is not without the support of version control, the built-in bag tracking system, Agile planning tools and many other features for developers of different "religions" and "suits". And, of course, Java developers will also find useful functionality for DevOps automation of their solutions. How they can effectively use the capabilities of VSTS, and will be discussed in our article today.
Over the 20 years of its existence, the Java platform has formed around itself a rich ecosystem of various tools for building, deploying, testing applications that Java developers use in everyday practice, and many of which, in fact, have already become the industry standard (Maven, Gradle, Ant , JUnit, JMeter and many others). And, of course, each developer or team has their own preferences for choosing tools: someone is used to building a project using Maven, and someone uses Gradle. The main idea of VSTS is to provide developers with opportunities that will allow you to build CI / CD processes as flexibly as possible, using familiar and familiar OSS tools for assembly, deployment, testing. VSTS is a cloud platform (unlike Microsoft Team Foundation Server, which is deployed on-premise), however, thanks to such a mechanism as build agents , which we will discuss below, you can build, for example, on-premise (in your data center), and, of course, on your virtual machines in the clouds (Azure, AWS, Google and other platforms).
Most clearly, the capabilities of VSTS can be illustrated with a simple Java application example with a complete build and deployment cycle. Immediately make a reservation that I will not describe a complete and detailed step-by-step tutorial, the purpose of this article is to convey the idea of using the VSTS platform for Java DevOps processes .
For our experiments, you will need a Microsoft Visual Studio Team Services account. You can get it for free.using your Microsoft Account or by creating a new one.
So, we will begin our fascinating journey. After registering, we need to create a project.
Specify the name of the project, Git as a version control system and create a new project.
After creating the project, VSTS automatically creates a new Git repository and offers to clone it on your work machine using the Git CLI or clone and open it in the Java IDE, for example, IntelliJ IDEA , is also supported by Eclipse . There are plugins for integrating with VSTS for these two IDEs.
We will return to integration with the IDE in our article a little later, but for now we are just cloning the code from GitHub. Click Import, specify the URL of our GitHub repository ( https://github.com/easkerov/SampleJava.git) and complete the import. In our case, the repository is public and authorization is not needed, but, of course, you can use private repositories by specifying the credentials you need to access.
After the import is completed, Files explorer will be opened for our repository, where you can add and make changes to application artifacts, switch between branches or create new ones. Of course, within the framework of one project, there can be several repositories, and you can configure separate CI / CD processes for them.
And we move on to the next stage - the assembly of our application. To do this, we need to create a Build Definition in our project.
VSTS has 2 important concepts related to configuring CI / CD processes. itdetermining assembly (Build Definition) and determination of the release (Release Definition) . Both definitions allow you to very flexibly build DevOps processes through the concept of tasks. Tasks can be of different types: for example, building a project in Maven, executing a Bash script, building a Docker container, copying files, deploying an application in a Tomcat container - these are all examples of tasks from which you can build your CI / CD processes. When creating a definition of the assembly process, you can use an already-prepared template with a given set of tasks for a specific task (for example, assembling a project in Maven / Gradle) or create an empty assembly definition and define the set of tasks in this process yourself. In our case, we will select an empty template and define the tasks in it ourselves.
The assembly and publication order of our application will be as follows: the first step is to install all the front-end dependencies using the Bower package manager, then collect our application in Maven, as a result we get a war artifact, which we put in a Docker container with Tomcat and publish it in the Docker Registry (in our case, it will be a private registry based on the Azure Container Registry ).
Having created an empty template, we must define the necessary tasks in it. Each step of our CI process is a separate task. For example, the Bower assembly is a separate task that we need to add to our CI pipeline and configure it. However, not all tasks are available in VSTS out of the box. For example, Bower has no default task in VSTS. But, fortunately, there is a Visual Studio Marketplacewhere Microsoft and third-party developers publish VSTS extensions for integration with various tools. Installing these extensions in VSTS is extremely simple, just find the module you need and install it in your environment by clicking Install and specifying your VSTS account.
Before defining specific tasks for the assembly of our application, it is necessary to indicate where the assembly of our application will take place. We can collect it using the mechanism of build and release / deployment agents (Build / Release agents) which is in VSTS. Agents can be of two types: hosted and private . Hostedagents are the easiest to use, since these environments (VM) for assembly are allocated to us by the VSTS platform itself with all the ensuing advantages of cloud computing (maintenance, upgrade, etc.). And there is a choice of OS for the environment - it can be Windows / Linux (the latter is still in preview). But what if we have a difficult case, and the environment in which we will build the Java application needs a specific complex configuration of the assembly components (for example, you need to define a private Maven repository in settings.xml ). In this case, you can deploy the environment yourself (on Linux / Windows / MacOS), install the Private Build Agent and initiate the assembly of the application in it from the VSTS console. Moreover, its own environment (VM) can be deployed in the clouds (Azure, Google, AWS) or in its own data center.
For our example, a Hosted agent on a Linux machine is sufficient. You must set this explicitly in the process settings (Process).
Next, we build the CI process, and determine the tasks that will be performed in it.
There will be 6 tasks in our CI process. Let's take a closer look at what it will consist of.
Before starting the assembly, the cloning of files from the Git repository of the project into the current environment (virtual machine) occurs automatically, then VSTS performs the sequence of tasks that we specified in the assembly definition.
Bower.Install.The first task, Bower.Install, allows us to install all the front-end dependencies using the Bower package manager. To do this, you just need to correctly configure the task parameters. As can be seen from the screenshot above, the configuration is simple and does not require special comments (unless you need to specify explicitly --allow-root ).
Maven.Build. In the second step, we build the application using the Maven task and the pom.xml artifact from the Git repository of our application. In addition to the task name and Maven goals, you can configure the parameters for publishing JUnit tests, specify JDK settings (version, architecture, memory settings, etc.), as well as connect tools for static code analysis (SonarQube, Checkstyle, PMD, FindBugs) and coverage code (JaCoCo, Cobertura, etc.).
Docker.ImageBuild. In the third step, we build the Docker image using the ready-made Dockerfile from the Git repository of our project. For this step, the Docker task is used (which will be used in the next step). As the Action parameter, we select Build an image and Dockerfile. Additionally, you can also specify options for assembling the image.
Docker.ImagePush. In the fourth step, the image we collected in the previous step of the Docker image is published in the private Docker registry, in our case, the registry uses the Azure Container Registry (ACR), but you can use other private / public Docker registry (Docker Hub). Please note that here we use the same Docker task as in the previous step, but the Action parameter in this case is set to Push an Image . As the name of the image that we collect and publish, we specify the expression devopsdemoregistry.azurecr.io/javademo:v$(Build.BuildId) , where $ (Build.BuildId) is the variable with the ID of the current assembly.
We are going to deploy the application to the cloud-based container service Azure Container Service and we will use the well-known Kubernetes as a container management system . A YAML manifest was prepared for publication with a description of the deployment and service objects of Kubernetes.
Shell script In the YAML artifact, you need to correctly define the Docker image, which we are going to use in the deployment. In the case of each new assembly, we mark each assembled Docker image with our application using the Build ID in the image tag, respectively, and when deploying, in the CD process we must start the deployment process using the image with the Build Id we need. To do this, in the YAML manifest, the desired image is determined by substituting the parameter value, and this happens in step 5 using the Shell Script task and Linux sed command .
Publish Artifact.Finally, we come to the final, 6th step of our CI process. Since the application runs in a container, whose Docker image we published in ACR in step 4, we will not publish any other application artifacts. The only artifact we need for the CD process is a modified YAML manifest for deployment to Kubernetes. We will publish it at this step. The published YAML artifact will be used later in the release definition to deploy the application through the Kubernetes task.
Our CI process is almost configured, there are only a few additional settings left, and we can check the build process. To start the CI process after each change in the selected source code branch (for example, master), you must enable the Continuous Integration optionin the properties of the Build Definition. In addition, you can turn on the Scheduled build option at the same time.
Our build definition is ready and now is the time to test it. Click Save & queue, then VSTS will ask us to confirm the build settings, and enjoy the process.
After placing the assembly in the queue, the process will be assigned a Build ID, which VSTS will tell us about.
By clicking on the link with the Build ID, you will see the process of assembling and completing the tasks that we defined earlier. After the assembly is completed, you can view the statistics of tests, code coverage (if you have configured), logs and, finally, download artifacts that were published as a result of the assembly.
We publish our Docker image after each build in the Azure Container Registry and open the Azure Portalconsole, for our registry, we can really make sure that our image is published.
After completing the CI process, we are ready to move on and configure the CD process for our Java application. To do this, we need to create a new Release Definition in our project.
For the application, we will use an empty definition and add the necessary tasks to it.
At the next step, VSTS suggests specifying the project and assembly definition on the basis of which our deployment will take place. Additionally, enable the Continuous deployment option , which means that the deployment will begin immediately after the successful completion of the assembly (CI process) for our application.
For the CD process, you need to make some settings: give a meaningful name to the definition and the CD environment and select the Release Agent that will be used for deployment. In our case, we continue to use Hosted Linux Preview . Pay attention to the concept of environment in the context of Release Definition. Environments are logical entities that determine where we will deploy the application. In our simple example, this is only the Dev environment, but for industrial solutions Test, Q&A, Stage, Prod environments, etc. can be added here. Accordingly, each environment can have its own set of tasks, with different deployment algorithms in different physical or virtual environments. In addition, there is a special approvals mechanism that allows you to not start deployment in the following environment until a user or group of users with the appropriate rights approves (or refuses) to continue the CD process. For example, deploying applications in Prod after Stage only after the approval of one or more users.
Now we are ready to add one single task for the CD process - Kubernetes task . However, by default this extension is not in the VSTS directory, but the Visual Studio Marketplace , which I mentioned above, helps out again , where you can find and install it for your VSTS account.
In fact, in the Kubernetes task, the kubectl CLI is used and with the apply command our YAML manifest is applied and the application is deployed to Kubernetes (I remind you that we are going to publish the application to the cloud container service Azure Container Service ).
The CD process is ready and it's time to start the deployment.
After starting the deployment, we will see our process in the list, after that you can open it and track the progress and the result.
As you can see from the execution results, the CD process completed successfully and the deployment and service objects were created successfully in Kubernetes.
Deployment results can be verified by checking the status of pods, deployments and services through the kubectl CLI. And of course, just by clicking on the link in your favorite browser: http: //: 8080
VSTS supports integration with various IDEs, allowing developers to work with the platform without essentially leaving the boundaries of their development environment. That is, to browse the list of tasks assigned to you, conduct a code review, create Pull Requests and much more, not to mention the usual work with the GIT repository. Plug-ins integration is currently supported for popular Java IDEs: IntelliJ IDEA, Android Studio, Eclipse.
Let's check with a simple example how this works for the IntelliJ IDEA IDE. To do this, install the plug-in for VSTS. Where to download it, and how to install it is described here .
Suppose we were assigned a new task from backlog to VSTS and a new Git branch named homepage was pre-created(This operation can be done in the VSTS console). The first step is to clone the desired Git repository on a working machine. The easiest way to do this is to use the Clone option and select IntelliJ IDEA. A special script will automatically launch the IDE and checkout process.
For example, edit the index.jsp file to add a new item to the list with the Deployment heading and do commit and push.
In the Commit window, in addition to the basic settings, you can specify the immediate task with which this commit is associated. Next, do commit and push.
The next step is to create a pull request directly in IntelliJ IDEA and specify the master branch as the target branch. We also specify our last commit as changes and create a pull request.
After creating the pull request, it can be opened and viewed in the VSTS console in the browser.
To complete the pull request, it must be approved. Access for approval is granted to users or a group of users with special rights in VSTS. After the approve process is complete, the pull request can be completed.
If necessary, you can delete the working branch homepage, which we used to develop a certain application functionality and make squash merge.
Merging changes to the master branch automatically initiates the CI / CD process of building, testing and deploying our application in the Azure Container Service. By going to the Build & Release section , you can track the build and deployment progress.
After completing the CI / CD processes, open your favorite browser and enjoy the changes in the application.
This article considered only a simple example of using VSTS in Java DevOps and some aspects were not considered in detail, for example, integration with code coverage tools (JaCoCo, Cobertura) and static code analysis (SonarQube, PMD, CheckStyle and so on). As I noted at the beginning of the article, the biggest advantage of the VSTS platform for developers is its flexibility, versatility, extensibility and simplicity, and here the motto “Any Developer, Any Language, Any Platform” fully justifies itself!
Microsoft Visual Studio Team Services- This is a DevOps cloud platform that allows you to flexibly build DevOps processes for continuous integration, assembly and deployment (CI / CD). Of course, this is not without the support of version control, the built-in bag tracking system, Agile planning tools and many other features for developers of different "religions" and "suits". And, of course, Java developers will also find useful functionality for DevOps automation of their solutions. How they can effectively use the capabilities of VSTS, and will be discussed in our article today.
Over the 20 years of its existence, the Java platform has formed around itself a rich ecosystem of various tools for building, deploying, testing applications that Java developers use in everyday practice, and many of which, in fact, have already become the industry standard (Maven, Gradle, Ant , JUnit, JMeter and many others). And, of course, each developer or team has their own preferences for choosing tools: someone is used to building a project using Maven, and someone uses Gradle. The main idea of VSTS is to provide developers with opportunities that will allow you to build CI / CD processes as flexibly as possible, using familiar and familiar OSS tools for assembly, deployment, testing. VSTS is a cloud platform (unlike Microsoft Team Foundation Server, which is deployed on-premise), however, thanks to such a mechanism as build agents , which we will discuss below, you can build, for example, on-premise (in your data center), and, of course, on your virtual machines in the clouds (Azure, AWS, Google and other platforms).
Most clearly, the capabilities of VSTS can be illustrated with a simple Java application example with a complete build and deployment cycle. Immediately make a reservation that I will not describe a complete and detailed step-by-step tutorial, the purpose of this article is to convey the idea of using the VSTS platform for Java DevOps processes .
For our experiments, you will need a Microsoft Visual Studio Team Services account. You can get it for free.using your Microsoft Account or by creating a new one.
So, we will begin our fascinating journey. After registering, we need to create a project.
Specify the name of the project, Git as a version control system and create a new project.
After creating the project, VSTS automatically creates a new Git repository and offers to clone it on your work machine using the Git CLI or clone and open it in the Java IDE, for example, IntelliJ IDEA , is also supported by Eclipse . There are plugins for integrating with VSTS for these two IDEs.
We will return to integration with the IDE in our article a little later, but for now we are just cloning the code from GitHub. Click Import, specify the URL of our GitHub repository ( https://github.com/easkerov/SampleJava.git) and complete the import. In our case, the repository is public and authorization is not needed, but, of course, you can use private repositories by specifying the credentials you need to access.
After the import is completed, Files explorer will be opened for our repository, where you can add and make changes to application artifacts, switch between branches or create new ones. Of course, within the framework of one project, there can be several repositories, and you can configure separate CI / CD processes for them.
And we move on to the next stage - the assembly of our application. To do this, we need to create a Build Definition in our project.
VSTS has 2 important concepts related to configuring CI / CD processes. itdetermining assembly (Build Definition) and determination of the release (Release Definition) . Both definitions allow you to very flexibly build DevOps processes through the concept of tasks. Tasks can be of different types: for example, building a project in Maven, executing a Bash script, building a Docker container, copying files, deploying an application in a Tomcat container - these are all examples of tasks from which you can build your CI / CD processes. When creating a definition of the assembly process, you can use an already-prepared template with a given set of tasks for a specific task (for example, assembling a project in Maven / Gradle) or create an empty assembly definition and define the set of tasks in this process yourself. In our case, we will select an empty template and define the tasks in it ourselves.
The assembly and publication order of our application will be as follows: the first step is to install all the front-end dependencies using the Bower package manager, then collect our application in Maven, as a result we get a war artifact, which we put in a Docker container with Tomcat and publish it in the Docker Registry (in our case, it will be a private registry based on the Azure Container Registry ).
Having created an empty template, we must define the necessary tasks in it. Each step of our CI process is a separate task. For example, the Bower assembly is a separate task that we need to add to our CI pipeline and configure it. However, not all tasks are available in VSTS out of the box. For example, Bower has no default task in VSTS. But, fortunately, there is a Visual Studio Marketplacewhere Microsoft and third-party developers publish VSTS extensions for integration with various tools. Installing these extensions in VSTS is extremely simple, just find the module you need and install it in your environment by clicking Install and specifying your VSTS account.
Before defining specific tasks for the assembly of our application, it is necessary to indicate where the assembly of our application will take place. We can collect it using the mechanism of build and release / deployment agents (Build / Release agents) which is in VSTS. Agents can be of two types: hosted and private . Hostedagents are the easiest to use, since these environments (VM) for assembly are allocated to us by the VSTS platform itself with all the ensuing advantages of cloud computing (maintenance, upgrade, etc.). And there is a choice of OS for the environment - it can be Windows / Linux (the latter is still in preview). But what if we have a difficult case, and the environment in which we will build the Java application needs a specific complex configuration of the assembly components (for example, you need to define a private Maven repository in settings.xml ). In this case, you can deploy the environment yourself (on Linux / Windows / MacOS), install the Private Build Agent and initiate the assembly of the application in it from the VSTS console. Moreover, its own environment (VM) can be deployed in the clouds (Azure, Google, AWS) or in its own data center.
For our example, a Hosted agent on a Linux machine is sufficient. You must set this explicitly in the process settings (Process).
Next, we build the CI process, and determine the tasks that will be performed in it.
There will be 6 tasks in our CI process. Let's take a closer look at what it will consist of.
Before starting the assembly, the cloning of files from the Git repository of the project into the current environment (virtual machine) occurs automatically, then VSTS performs the sequence of tasks that we specified in the assembly definition.
Bower.Install.The first task, Bower.Install, allows us to install all the front-end dependencies using the Bower package manager. To do this, you just need to correctly configure the task parameters. As can be seen from the screenshot above, the configuration is simple and does not require special comments (unless you need to specify explicitly --allow-root ).
Maven.Build. In the second step, we build the application using the Maven task and the pom.xml artifact from the Git repository of our application. In addition to the task name and Maven goals, you can configure the parameters for publishing JUnit tests, specify JDK settings (version, architecture, memory settings, etc.), as well as connect tools for static code analysis (SonarQube, Checkstyle, PMD, FindBugs) and coverage code (JaCoCo, Cobertura, etc.).
Docker.ImageBuild. In the third step, we build the Docker image using the ready-made Dockerfile from the Git repository of our project. For this step, the Docker task is used (which will be used in the next step). As the Action parameter, we select Build an image and Dockerfile. Additionally, you can also specify options for assembling the image.
Docker.ImagePush. In the fourth step, the image we collected in the previous step of the Docker image is published in the private Docker registry, in our case, the registry uses the Azure Container Registry (ACR), but you can use other private / public Docker registry (Docker Hub). Please note that here we use the same Docker task as in the previous step, but the Action parameter in this case is set to Push an Image . As the name of the image that we collect and publish, we specify the expression devopsdemoregistry.azurecr.io/javademo:v$(Build.BuildId) , where $ (Build.BuildId) is the variable with the ID of the current assembly.
We are going to deploy the application to the cloud-based container service Azure Container Service and we will use the well-known Kubernetes as a container management system . A YAML manifest was prepared for publication with a description of the deployment and service objects of Kubernetes.
Shell script In the YAML artifact, you need to correctly define the Docker image, which we are going to use in the deployment. In the case of each new assembly, we mark each assembled Docker image with our application using the Build ID in the image tag, respectively, and when deploying, in the CD process we must start the deployment process using the image with the Build Id we need. To do this, in the YAML manifest, the desired image is determined by substituting the parameter value, and this happens in step 5 using the Shell Script task and Linux sed command .
Publish Artifact.Finally, we come to the final, 6th step of our CI process. Since the application runs in a container, whose Docker image we published in ACR in step 4, we will not publish any other application artifacts. The only artifact we need for the CD process is a modified YAML manifest for deployment to Kubernetes. We will publish it at this step. The published YAML artifact will be used later in the release definition to deploy the application through the Kubernetes task.
Our CI process is almost configured, there are only a few additional settings left, and we can check the build process. To start the CI process after each change in the selected source code branch (for example, master), you must enable the Continuous Integration optionin the properties of the Build Definition. In addition, you can turn on the Scheduled build option at the same time.
Our build definition is ready and now is the time to test it. Click Save & queue, then VSTS will ask us to confirm the build settings, and enjoy the process.
After placing the assembly in the queue, the process will be assigned a Build ID, which VSTS will tell us about.
By clicking on the link with the Build ID, you will see the process of assembling and completing the tasks that we defined earlier. After the assembly is completed, you can view the statistics of tests, code coverage (if you have configured), logs and, finally, download artifacts that were published as a result of the assembly.
We publish our Docker image after each build in the Azure Container Registry and open the Azure Portalconsole, for our registry, we can really make sure that our image is published.
After completing the CI process, we are ready to move on and configure the CD process for our Java application. To do this, we need to create a new Release Definition in our project.
For the application, we will use an empty definition and add the necessary tasks to it.
At the next step, VSTS suggests specifying the project and assembly definition on the basis of which our deployment will take place. Additionally, enable the Continuous deployment option , which means that the deployment will begin immediately after the successful completion of the assembly (CI process) for our application.
For the CD process, you need to make some settings: give a meaningful name to the definition and the CD environment and select the Release Agent that will be used for deployment. In our case, we continue to use Hosted Linux Preview . Pay attention to the concept of environment in the context of Release Definition. Environments are logical entities that determine where we will deploy the application. In our simple example, this is only the Dev environment, but for industrial solutions Test, Q&A, Stage, Prod environments, etc. can be added here. Accordingly, each environment can have its own set of tasks, with different deployment algorithms in different physical or virtual environments. In addition, there is a special approvals mechanism that allows you to not start deployment in the following environment until a user or group of users with the appropriate rights approves (or refuses) to continue the CD process. For example, deploying applications in Prod after Stage only after the approval of one or more users.
Now we are ready to add one single task for the CD process - Kubernetes task . However, by default this extension is not in the VSTS directory, but the Visual Studio Marketplace , which I mentioned above, helps out again , where you can find and install it for your VSTS account.
In fact, in the Kubernetes task, the kubectl CLI is used and with the apply command our YAML manifest is applied and the application is deployed to Kubernetes (I remind you that we are going to publish the application to the cloud container service Azure Container Service ).
The CD process is ready and it's time to start the deployment.
After starting the deployment, we will see our process in the list, after that you can open it and track the progress and the result.
As you can see from the execution results, the CD process completed successfully and the deployment and service objects were created successfully in Kubernetes.
Deployment results can be verified by checking the status of pods, deployments and services through the kubectl CLI. And of course, just by clicking on the link in your favorite browser: http: //
And what else is useful for Java developers in VSTS?
VSTS supports integration with various IDEs, allowing developers to work with the platform without essentially leaving the boundaries of their development environment. That is, to browse the list of tasks assigned to you, conduct a code review, create Pull Requests and much more, not to mention the usual work with the GIT repository. Plug-ins integration is currently supported for popular Java IDEs: IntelliJ IDEA, Android Studio, Eclipse.
Let's check with a simple example how this works for the IntelliJ IDEA IDE. To do this, install the plug-in for VSTS. Where to download it, and how to install it is described here .
Suppose we were assigned a new task from backlog to VSTS and a new Git branch named homepage was pre-created(This operation can be done in the VSTS console). The first step is to clone the desired Git repository on a working machine. The easiest way to do this is to use the Clone option and select IntelliJ IDEA. A special script will automatically launch the IDE and checkout process.
For example, edit the index.jsp file to add a new item to the list with the Deployment heading and do commit and push.
In the Commit window, in addition to the basic settings, you can specify the immediate task with which this commit is associated. Next, do commit and push.
The next step is to create a pull request directly in IntelliJ IDEA and specify the master branch as the target branch. We also specify our last commit as changes and create a pull request.
After creating the pull request, it can be opened and viewed in the VSTS console in the browser.
To complete the pull request, it must be approved. Access for approval is granted to users or a group of users with special rights in VSTS. After the approve process is complete, the pull request can be completed.
If necessary, you can delete the working branch homepage, which we used to develop a certain application functionality and make squash merge.
Merging changes to the master branch automatically initiates the CI / CD process of building, testing and deploying our application in the Azure Container Service. By going to the Build & Release section , you can track the build and deployment progress.
After completing the CI / CD processes, open your favorite browser and enjoy the changes in the application.
FAQ
- I have a CI process built in Jenkins, why do I need VSTS? Jenkins and VSTS integrate well and complement each other. For example, you can continue to use Jenkins Server for CI builds (on-premise or in the clouds), and for CD processes use VSTS. Moreover, you may have a complex CI process where assembly in Jenkins is only part of the assembly definition in VSTS. Jenkins integration with VSTS is carried out using a special Team Foundation Server Plugin module.
- What about load testing? Can I use JMeter in VSTS? Yes, Apache JMeter is already available out of the box in VSTS. How to use it can be found in the documentation .
- Can I write my own extension for VSTS? Yes, you can, a special SDK for developers is available. See here for more information: Write your first extension for Visual Studio Team Services .
- Where can I find additional materials and examples about Java development in VSTS? There is a separate portal for Java developers with information, examples, and tutorials on using VSTS in Java development: http://java.visualstudio.com/ . And of course, the official VSTS documentation is available .
Conclusion
This article considered only a simple example of using VSTS in Java DevOps and some aspects were not considered in detail, for example, integration with code coverage tools (JaCoCo, Cobertura) and static code analysis (SonarQube, PMD, CheckStyle and so on). As I noted at the beginning of the article, the biggest advantage of the VSTS platform for developers is its flexibility, versatility, extensibility and simplicity, and here the motto “Any Developer, Any Language, Any Platform” fully justifies itself!