We receive a notification that there’s a pull request to review for our Team Services extensibility project. We discuss the proposed changes as a team, eventually merge the new feature(s) into the master branch, and close the pull request. Done … right?
Not quite. The merge triggers our automated CI/CD pipeline, which consistently builds and delivers our package to the Visual Studio marketplace.
If you’re interested in how we configured our Folder Management Extension pipeline or looking for options to configure your own, you should read on.
Let’s walk through the configuration of our pipeline.
Build
We start with the continuous integration build, made up of seven steps, as shown.
| # | BUILD STEP | BUILD SNIPPET | WHAT’S HAPPENING? |
| 1 | Install npm dependencies | Install all modules listed as dependencies in package.json. | |
| 2 | Initialize npm | Run the package setup script, as defined under “scripts” in package.json. | |
| 3 | Replace tokens in TelemetryClient |
We replace the INSTRUMENTATION key in the TelemetryClient.ts file with the value of the variable with the same name. Token Regex is “__(w+)__”, which means that we’re looking for one or more letter, digit or underscore characters, surrounded by a double underscore “__name__”. Variables
|
|
| 4 | Build solution | We build the extension, as outlined by the FolderManagement.sln solution file. | |
| 5 | Whitesource | Scan and detect security vulnerabilities, problematic OSS licenses and quality issues. See Manage your open source usage and security in your pipeline for details. | |
| 6 | Package Extension |
We package the extension using the Vsts Developer Tools Build Tasks extension and generate the output.vsix artifact. Extension ID is appended with Alpha to differentiate it from deployed DEV, BETA, and PROD packages. |
|
| 7 | Publish Artifact | We publish the artifact, output.vsix, to $(Extension.OutputPath) to be picked up by the release. |
What about automated testing? We’re intentionally keeping this pipeline simple. We’ll cover automated unit testing and code coverage in the “Set up a CI/CD pipeline with unit testing and code coverage for your Team Services extension” (COMING SOON) post.
Release
Next we continue with continuous delivery (CD), made up of three simple environments.
Continuous Delivery is the ability to use the output from the CI to build and deploy the new known good build to one or more environments automatically (bit.ly/28PWsfk). There is a subtle difference between Continuous Delivery and Continuous Deployment. The latter is to a single environment. A small team might only implement Continuous Deployment because each change goes directly to production. Continuous Delivery is moving code through several environments, ultimately ending up in production, which may include automated UI, load and performance tests and approvals along the way. – Extract from DevOps – Applying DevOps to a Software Development Project
DEV
The environment with one task is triggered after a successful release creation. Both the pre-deployment and post-deployment approvals are automatic, ensuring that the development team is always working with the latest version. There’s no manual intervention.
| # | RELEASE STEP | BUILD SNIPPET | WHAT’S HAPPENING? |
| 1 | Publish Extension |
We publish the extension to the alm-rangers publisher, using the VSTS Developer Tools Build Tasks extension.
|
BETA
The environment with only one task is triggered after a successful deployment to the DEV environment. The BETA approvals mandate that one of the specified users approve the release, to ensure that a high quality bar can be met. Users typically include the project lead and program manager.
| # | RELEASE STEP | BUILD SNIPPET | WHAT’S HAPPENING? |
| 1 | Publish Extension |
We publish the extension to the alm-rangers publisher, using the VSTS Developer Tools Build Tasks extension.
|
PROD
The environment with only one task is triggered after a successful deployment to the BETA environment. The PROD approvals mandate that all of the specified users approve the release, to ensure that we publish the highest quality. Users typically include the project lead, product owner, and program manager.
| # | BUILD STEP | BUILD SNIPPET | WHAT’S HAPPENING? |
| 1 | Publish Extension |
We publish the extension to the ms-devlabs publisher, using the VSTS Developer Tools Build Tasks extension.
|
That’s it! Consistent and simple!
Now that you have an understanding of how our pipeline works, you should explore how you can configure your continuous integration and delivery pipeline by #RubDevOpsOnIt. In the next post, we’ll take a look at our more complex Countdown Widget pipeline, which includes unit testing and code coverage.
Other pipelines examples
Reference Information
DevOps – Applying DevOps to a Software Development Project, VSTS Developer Tools Build Tasks
This post first appeared on MSDN Blogs | Get The Latest Information, Insights, Announcements, And News From Microsoft Experts And Developers In The MSDN Blogs., please read the originial post: here
