April 6, 2016 at 15:05

How We Deployed DevOps: Continuous Integration with GitHub and the Visual Studio Team Services Build System

Original author: Julien Corioland
  • Transfer
  • Tutorial


Hello! We continue the series of articles “How We Deployed DevOps” by the Vorlon.JS team.
Vorlon.JS is a node.js-based tool that allows web developers a convenient way to remotely test, control and debug a web application, especially on mobile and embedded systems. In its blog on MSDN, the team described in detail the phased implementation of DevOps practices in organizing work on Vorlon.JS and the selection of tools for solving daily tasks. Vorlon.JS is an open source project .
Microsoft offers a large number of tools that can be used to implement DevOps practices, and in this series we will talk in detail about Visual Studio Team Services, Visual Studio Code and work with Microsoft Azure. Of course, we’ll also touch on the possibility of using many non-Microsoft tools, including when deploying applications to Microsoft Azure.

Cycle content:
  • Project Planning and Management with Visual Studio Team Services
  • Continuous integration with GitHub and Visual Studio Team Services build system
  • ASA framework with Microsoft Azure and Azure Resource Manager
  • Release Management in Visual Studio Team Services
  • Testing in a production environment with Microsoft Azure App Service and Web Apps

You may already know that Visual Studio Team Services (VSTS) provides source control tools that support GIT or TFVSC (Team Foundation Version Source Control).

In this article, we will explain in detail how easy it is to implement continuous integration for code hosted on GitHub using Visual Studio Team Services.

Pay attention to the previous article in the series , if you do not already have a VSTS account, it tells in detail how to get it for free.

Connect GitHub to Visual Studio Team Services


To start working with GitHub, first of all, you need to connect your account on the page for configuring external services in VSTS.

Go to the project settings of the team by clicking on the six in the upper right corner of the window, and then select the “Services” tab. You can add a new connection to the service, including GitHub, if you click on the “New Service Endpoint” button . Click on the Authorize button to connect to the GitHub account and use your GitHub account information for authentication.





Creating an assembly definition


Once you have set up your GitHub account, return to the team project and press “BUILD” to access the build definitions.

The new build service is an open system that can run various build agents (Linux, Windows, etc.) and handle a large number of build tasks such as MSBuild, Maven, Ant, create packages for Android applications, perform NPM or Gulp tasks etc.

In fact, the build system is completely open and provides the ability to create your own tasks, if provided from the box are not suitable for your purposes. All existing tasks are publicly available in the GitHub repository. It also presents the tasks for creating application packages and deploying them (Azure Resource Manager, Web App, Docker, Tom Cat ..), but we will discuss them a bit later in the article, where we will talk about Release Management with VSTS.

In general, you only need to take a few steps to create a new assembly definition.

Define tasks for shaping the assembly process


This is the most important step, and it may take longer, depending on the solution you want to build. In the case of Vorlon.JS, we needed the following:
  • Running NPM install in order to add all the dependencies of the application, and performing the default Gulp task, which will generate JavaScript and CSS files from TypeScript, Less, etc.
  • Launching a “test” Gulp task responsible for running unit tests with Mocha.JS
  • Launching the “zip” Gulp task responsible for creating the zip archive containing the application
  • Publish assembly artifacts (the zip file created in the previous step, and other deployment scripts, which we will discuss in the next article). These artifacts will be used by the Release Management service to publish the application to various environments (dvelopment, QA, pre-production, production ...)

On the Build tab, click on the plus on the left to create a new build definition. You can select either an existing template or an empty definition: In this case, I selected an empty definition. Click “Next” to access the “Settings” page, where you can configure the type of repository for storing the source code that will be associated with the new assembly, the agent queue for using them when the assembly was initiated, and if you want to use continuous integration, in order to start the assembly every time a commit has been made, the corresponding setting must be noted: There are two types of assembly agents that can be used:








  • Hosted build agents - provided as a service in Visual Studio Team Services, and you pay for their use in minutes
  • Private build agents - those that you can configure on your own / virtual machines, they can run on Windows or Linux.

At this step, we can use the Hosted agent, which will natively support all the tools that we will use for the build process.

Click Create to create the assembly definition. You will be redirected to the assembly definition constructor, which will allow you to determine the process to execute during assembly. The assembly consists of steps that will be performed one after another.

Click "Add build step". You can choose various steps to add to the process: The following is the process that we defined for the Vorlon.JS assembly:







As you can see, each step can be configured in the area on the right. For example, the first “NPM install” task will be executed after the repository has been cloned. Then two gulp tasks will be executed: the first will perform unit testing with Gulp using the Mocha.JS framework, the second will generate a zip archive with all the code and root modules. The latter task is used to publish assembly artifacts to the assembly agent in order to be able to use these artifacts during the Release Management stage to deploy the application.



Repository definition


Once you have added all the necessary steps for your build process, return to the “Repository” tab to configure the source code repository that this build definition should use. In the case of Vorlon.JS, we used the GitHub repository:



We initiate assembly


In this project, we wanted the new build to start as soon as the source code changes in the GitHub repository were made. To configure this, you need to go to the “Triggers” tab and select Continuous Integration, as shown in the screenshot: You can also choose to start scheduled builds for various repository branches, for example, launch nightly builds: Click “Save” on the panel. For the first time, a popup will ask you to specify the name of the assembly.









The next step is to make changes to the code and commit to the repository to check if the build process is starting and everything works well. Here we use GitHub, but all the steps taken to create the assembly definition can be done with the participation of other providers in VSTS (GIT or TFVSC), so the use of GitHub is optional!
In our case, we use the Visual Studio Code tool, which provides native integration with GIT, so it becomes very easy to program, and then immediately send the changes to GitHub.

Verify build results and output


To access the latest assembly, click on the assembly definition on the left. You can choose to display assemblies in the queue and completed assemblies.
Once the assembly is completed, you can access the logs directly on the VSTS portal to see if all the assembly steps were completed correctly: you can get logs for each step: It is also possible to download assembly artifacts from the portal, so that you can see that was published to the assembly agent during the execution of the entire process. We will use these artifacts in a future release management article.













But before we get down to the topic of release management, in the next article in the series we will understand what the “Infrastructure-as-code” approach is and how it can improve the process of creating environments and deploying the application.

Stay in touch!

About Authors



Julien Corioland is a technology evangelist at Microsoft, France. After six years as a consultant, he is Microsoft's technical evangelist in France. The main area of ​​work is the Microsoft Azure application platform. He helps developers create cloud applications, and is also part of the Vorlon.JS tool development group, in which he helps implement DevOps practices.

We are pleased to announce that the developers of the Vorlon.JS project - Julien Corioland and Ettiene Margraff will be speakers at the DevCon 2016 conference, where they will exclusively talk about their experience in implementing live practices and provide an opportunity to build these processes on their own. hands.

If you have any questions about this series of publicationsor about the DevOps methodology, you can contact the author directly via Twitter: twitter.com/jcorioland

useful links


Tags:

Also popular now: