“Zero touch testing and deployments” is a common DevOps mantra for your continuous integration and continuous deployment (CI/CD) pipeline. Also for you frontend projects.
In this post a how to use and configure Visual Studio Team Services for this CI/CD practice on Angular2 projects. Continue reading and/or watch this overview video:
The Angular2 Project.
The heavy lifting and thinking of setting up all these libraries and tasks is already done by the contributors of this Angular2 Seed project.
After cloning this GitHub project getting it up and running in VSTS is easy. First run it local and make sure you have Java installed for Selenium.
Setup Visual Studio Team Services.
GIT and GitGFlow
After creating a VSTS account and a scrum project with GIT as versioning system, you can configure the branches with policies. See: Gitflow and VSO branch policies use them together and the VSTS documentation.
For the build system you need to create a custom build agent, during the build there is interaction with the UI and I use the Chrome browser for testing.
A perfect place to host this Build Agent VM is in Azure DevTest Labs. It takes care of the artifacts needed on the Build Agent and the schedule to start stop the VM. See this Channel9 video (in Dutch) and this Post.
The build agent is configured to run interactively, to make sure interaction with the UI is allowed. To make sure all the PATH variables are correct I start the Build Agent via the Node Command Line.
And also make sure Java is installed for running selenium.
Per branch two builds are configured, one which is activated by the Pull Request Branch Policy and the other at Integration when a Pull Request is approved. Four builds per Git repo (at start).
The CI build activates the deployment of the Angular2 App and has some more steps, like packages and run UI test. For the PR Build a minimal set of steps is configured, to make the build execute as fast as possible.
The PR Build has the steps to build the solution and run the unit tests in the project.
These steps are executed via the NPM Test command, which executes the Gulp Test task.
This is all default available in the Seed Project, only one additional task and customization is done for getting the Unit Test results in VSTS. In the karma.conf.js a trx reporter is added for output to trx.
And in the VSTS Build this output is published to VSTS.
This will make the Unit Test results appear in VSTS.
The CI Build has some more steps, next to the Get Deploy Tools (see next paragraph) and the Unit Test execution it also builds the Angular2 Project and makes it deployment ready.
This Build production activity is also already baked in the Angular2 Seed project in the GulpFile.ts.
Next the Gulp e2e task (also already there) will execute the Selenium Protractor UI tests. Also here only one customization is done to get the result in VSTS. The jasmine-trx-reporter is added as a report.
Which is published in VSTS via the Publish test result step.
Deploy the Angular2 App.
The Angular Application will land on Azure Web Apps. After creating this Web App via the Azure portal (normal done with ARM) and the three deployment slot (dev, test and staging), the deployment via VSTS Release can be configured.
For the deployment the published build artifacts from the CI build are used. As a deployment mechanism MSDeploy is used via PowersHell, where the parameters are coming from the PublishSettings file, downloaded from the Azure Portal.
cmd.exe /C $("msdeploy.exe -source:IisApp='$wwwroot' -dest:IisApp='$websiteName',computerName='https://$publishURL/msdeploy.axd',userName='$userName',password='$password',authtype='Basic',includeAcls='False' -verb:sync -enableLink:contentLibExtension -enableRule:AppOffline -retryAttempts:2")
This PowerShell file is made available for VSTS release via the build step GetDeployTools. The powershell script requires two parameters, the PublishSettingsFile and the build drop location.
Per Git repo there are two release activities, one for the develop branch and one for the master branch. The develop branch only pushes releases to the development and test deployment slots and the master release also to the staging and production after approval.
And all of this results in a nice controlled CI/CD release pipeline, and again the heavy thinking and work already is done by the contributors of the Angular2 Seed project.