Outline > Module 0: Start Here > Welcome to the course! > Welcome
Welcome to the course Introduction to DevOps! My name is Lei Ma. I work as a Content Developer at Microsoft and will be your host for this course. While designing and authoring this course, I had the privilege to work with a lot of DevOps experts at Microsoft and industry expert Steven Borg, who helped make this course happen.
We're very excited to have you join us and we hope that you have an enriching and engaging learning experience.
Before you get started with the course material, please read through the brief overview pages in this unit so you can become oriented to the course structure, the schedule, and how things will work in this course. As always, we welcome your feedback so if something is confusing or doesn't work the way you expect, let us know and we'll do our best to address it.
Please take a moment to introduce yourself in the discussion forum in this module. This will help fellow learners to know a little bit more about you and helps make later discussions a little bit easier.
To get help with the course, click the Discussion tab and post a question. To get help with a technical problem, click Help to send a message to edX Student Support. To begin, click the navigation buttons at the top of this page to read through the introductory material. You'll then be prepared to jump right in! Again, welcome and thanks for taking this course from Microsoft.
Outline > Module 0: Start Here > Welcome to the course! > Getting Around the Course
If you're new to edX, here is some information to help you get started. Even if you've used edX for other courses, the information here will help orient you on the layout of the course.
This course is laid out in modules and units. Each module contains 1 or more units that cover the material for that module. The module is the topic area and the units has all the learning material you'll need to learn that topic. To navigate through the module's units, use the navigation bar at the top of the module. You can use the left and right arrows to move through each unit.
Each unit will generally have some video content, reading material and problem sets, and a set of assessment questions to test your knowledge. Some units also have a discussion board where you can post questions and other material so fellow students can provide feedback. The units are meant to be taken in order but you can skip around if you already have mastered the material in a particular unit. In order to do well on the assessments, you should learn the material in all the units. Hover over the unit with your mouse to see the unit title.
Given the nature of this MOOC-style course and the large number of students enrolled, its not possible for instructors to provide feedback to students. However, we encourage you to seek help and feedback from your fellow students using the discussion boards. This is a great way to help each other out and enrich your learning experience.
edX Student FAQ: This FAQ answers a lot of questions about the edX student experience. You should at least read over the questions so if you encounter any issues during the course, you can refer back to this document for help.
Outline > Module 0: Start Here > Welcome to the course! > Meet Course Staff
[Video link: https://youtu.be/pIg_O6jN8kM]
[Video link: https://youtu.be/NFolWY6OqTU]
Outline > Module 0: Start Here > Course Overview > Course Overview
By taking this DevOps introductory course, you'll be able to define DevOps, understand why you need DevOps, and how you can get started with DevOps; you'll learn the key ideas and techniques to bring development and operations together to deliver software more quickly and produce higher-quality software.
[Video link: https://youtu.be/JmoVlafq7js]
Introduction to the definition, the value, the history, the building blocks and best practices of DevOps.
Introduction to how Agile software development process applies to DevOps, the importance of integrating source control in DevOps, and how automation is applied to DevOps.
Introduction to the key concepts, benefits, tools, and practices of implementing Continuous Integration (CI), continuous testing, and continuous delivery.
Introduction to the key concepts, benefits, tools and practices of implementing release and configuration management in a DevOps environment.
Introduction to the key concepts, benefits, tools and practices of implementing monitoring, feedback and learning in DevOps.
Outline > Module 0: Start Here > Course Overview > Audience
This is an introductory DevOps course. It's for anyone who is involved in the development, delivery, or ongoing operations of software in an organization and interested in learning and adopting DevOps practice.
Prerequisites of this course include:
- Experience working inside an organization that delivers software;
- A basic understanding of source control and Agile software development process.
Outline > Module 0: Start Here > Course Overview > Grading
This course is graded by the following three assignment types:
- Module Assessments are a small handful of questions at the end of each module. These are designed to assess your progress in the course, and test your retention of the knowledge. Questions may be in the form of multiple choice, interactive items such as "drag and drop", or fill in the blank.
- Module Assessments will count towards 55% of the final grade
- Every module will have at least one exercise. Exercises give you the opportunity to reflect on what you've learned in the module and apply the knowledge to real-world scenarios. The exercises will be graded based on the completion of each task.
- Exercises will count towards 20% of the grade
- Final exam will count towards 25% of the grade
This course is graded as pass/fail, meaning you will either be given a passing score or a failing score. The score required to pass this course is 70%.
Outline > Module 0: Start Here > Pre-course survey > Course Survey
Please complete the survey below before starting the course. If the survey is not displayed in your browser you can complete it at https://mslexsurveys.azurewebsites.net/survey/260395 in a separate pane.
Course Survey
Outline > Module 1: Overview of DevOps > Introduction > Introduction to DevOps
[Video link: https://youtu.be/uo30tGAJS6E]
Outline > Module 1: Overview of DevOps > Introduction > Module Overview
In the first module, you'll learn:
- What DevOps is, what DevOps encompasses, a semi-holistic view of DevOps, and the common misconceptions about DevOps.
- What factors are driving the DevOps movement, what values DevOps can bring to your organization, and what evidence is available to show the effectiveness of DevOps.
- Where DevOps was initiated and how it has evolved for the past years.
- What the best practices and habits of DevOps are and how to measure the success of DevOps.
Outline > Module 1: Overview of DevOps > The Definition and Value of DevOps > Definition of DevOps
DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.
You cannot buy DevOps and install it. DevOps is not just automation or infrastructure as code. DevOps is people following a process enabled by products to deliver value to end users.
-- Donovan Brown, Microsoft DevOps Program Manager
For more information, see Donovan's blog post on "What is DevOps".
[Video link: LINK]
Outline > Module 1: Overview of DevOps > The Definition and Value of DevOps > The Value of DevOps
Over the past 15 years, agile software development has gained immense popularity among software development teams. The agile process accelerates the software development process and forces a faster release cadence.
However, traditional IT operations teams struggle with this increased release cadence. The current operation practices made the release and operation processes reliable, but not agile. Additionally, the disconnects between development and operations increase mistakes and lead time when issues occur.
By embracing the DevOps culture and practices, all team members who are involved in creating, delivering, and monitoring software, can work together to ensure high quality releases at increasing frequencies.
Here are the key values of DevOps. DevOps:
- Breaks walls of separation between teams and fosters better communication and collaboration throughout the application development lifecycle.
- Delivers software more frequently and produces higher quality software.
- Shortens lead time and software delivery cycles. (Lead time means the time required from code commit to code successfully running in production)
Puppet Labs published the State of DevOps Reports in the last five years based on responses from over 20,000 tech professionals worldwide. They concluded that organizations embracing DevOps practices consistently massively outperformed their peers. For example,
- Companies with high-performing IT organizations are twice as likely to exceed their profitability, market share and productivity goals.
- High-performing IT organizations experience 60X fewer failures and recover from failure 168X faster than their lower-performing peers. They also deploy 30X more frequently with 200X shorter lead times.
For more information, see 2016 State of DevOps Report, and Current State of DevOps Report.
[Video link: https://youtu.be/OT2Szw6IN3A]
Outline > Module 1: Overview of DevOps > The History of DevOps > The History of DevOps
The term "DevOps" was initiated relatively late. At the Agile 2008 conference in Canada, Andrew Clay Shafer and Patrick Debois discussed "Agile Infrastructure". The term "DevOps" was promoted through a series of DevOpsDays starting in 2009 in Belgium. Since then, DevOpsDays conferences have been held in many countries worldwide.
[Video link: https://youtu.be/Tbz52XzSZGU]
Outline > Module 1: Overview of DevOps > The History of DevOps > From Agile to DevOps at Microsoft Developer Division
Read this free e-book from Microsoft: From Agile to DevOps at Microsoft Developer Division e-book by Sam Guckenheimer.
Watch the following video by Sam Guckenheimer for a deeper dive of DevOps.
[Video link: https://youtu.be/8EN1kGFmiIo]
Outline > Module 1: Overview of DevOps > The History of DevOps > Microsoft DevOps Journey
Watch some videos from Microsoft Engineering about their DevOps journey:
[Video link: https://youtu.be/3FUhl3y0Qd4]
[Video link: https://youtu.be/EphPwecvAeM]
[Video link: https://youtu.be/KzQRd6jBE1Q]
[Video link: https://youtu.be/0MsjACD-Als]
For more information about Microsoft DevOps journey, see Microsoft engineering stories.
Outline > Module 1: Overview of DevOps > The Building Blocks of DevOps > Practices and Habits of DevOps
- Configuration Management
- Release Management
- Continuous Integration
- Continuous Deployment
- Infrastructure as Code
- Test Automation
- Application Performance Monitoring
- Team Autonomy and Enterprise Alignment
- Rigorous Management of Technical Debt
- Focus on Flow of Customer Value
- Hypothesis Driven Development
- Evidence Gathered in Production
- Live Site Culture
- Manage Infrastructure as a Flexible Resource
For more information, see Sam Guckenheimer's talk on the 7 habits of successful DevOps.
[Video link: https://youtu.be/QrwTD5eCkd4]
Outline > Module 1: Overview of DevOps > The Building Blocks of DevOps > DevOps Metrics
- Agility performance indicators, such as deployment frequency and change lead time.
- Reliability performance indicators, such as change fail rate and mean time to detect and repair.
[Video link: https://youtu.be/N8qqq2ubvOY]
Outline > Module 1: Overview of DevOps > Overview of Hands-on Labs and Prerequisites > Overview of Labs
The hands-on labs in this course aim to walk you through the creation of a DevOps/ Continuous Delivery pipeline, including infrastructure-as-code, configuration-as-code, as well as code deployment. We'll show you how to apply DevOps practices on deploying a fictitious ecommerce website called Parts Unlimited. The labs aren't required to successfully complete this course, but they are highly recommended as creating a pipeline really gives you a feel for the power of DevOps.
The Parts Unlimited website includes product listings by category, product details, shopping cart, order history, product recommendations, search, and more. The website is an open-source project, built on ASP.NET 5 MVC 6. It was created based on the book, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford.
Note: You don't need to understand the code in the application in order to follow the labs.
The demos below intend to give you a quick overview of the Parts Unlimited application and the power of a DevOps pipeline.
Note: Don't worry if you don't completely understand the concepts or process covered in the demos. Everything mentioned here will be explained in more details as we move forward in later modules.
[Video link: https://youtu.be/yDjdwMNP-rE]
[Video link: https://youtu.be/unr9EPwclQk]
For more information, you can see:
ASP.NET: https://aka.ms/edx-dev212x-asp
Visual Studio Team Services: https://aka.ms/edx-dev212x-vsts
Microsoft Azure: https://aka.ms/edx-dev212x-az01
Outline > Module 1: Overview of DevOps > Overview of Hands-on Labs and Prerequisites > Lab Prerequisites and Tools
For demo and labs purpose, we'll use Visual Studio Team Services (VSTS), the Azure platform, and Git in the course to illustrate the key concepts and practices of DevOps. Here are steps to sign up and configure lab dependencies and prerequisites:
- Create a Visual Studio Team Services (VSTS) account
- Create an Azure Free Trial account
- Download and install Git
- Sign into Visual Studio.
Enter your Microsoft Account credentials.
- Note: If you do not have a Microsoft Account, then you will need to create one by clicking "Sign up now". Once you have created an account, you can sign in using that account.
- Once you have signed in to your Microsoft account (or created a new one), you should see a panel to create a new Visual Studio Team Services account. Click on the "Create new account" button.
- In the "Create your account" panel, enter the following information:
-
A unique Visual Studio Team Services account name
-
Git as the version control for the team project
-
A project name, such as "PartsUnlimited" or "Intro-to-DevOps"
-
The Agile, Scrum, or CMMI template for organizing work in the project
Note: The project template defines what work item types and workflows are available. The Hands-on-labs can be completed with any of the three templates, but Agile or Scrum are more commonly used in DevOps organizations.
Once you have filled out the information, press the continue button to create the Visual Studio Team Services account.
- Once the project is created, you will be redirected to the Team Project dashboard. You can close the Congratulations dialog once you have read it.
Note: If you already have an Azure account, you can skip this step. However, you need to ensure that it is an account in which you are the account owner or administrator. In other words, if you create the account yourself, you can skip this step and just sign into your account. However, if someone else created the account and added you to the account, then you will need to ensure you have sufficient permissions.
To sign up for the Azure Free Trial, visit Azure Free Trial, and log in with a Microsoft ID. (You can use the same ID you created or used when setting up the VSTS account.) One catch is that you will need a credit card. This card is not charged, but it used to prevent bots from creating hundreds of free trials and getting free compute.
If you'd like to watch a video, showing how to sign up for a free Azure trial, visit the Sign up for Azure video on Channel9.
Alternatively, if you have an MSDN subscription, you can activate your free, monthly Azure credits (up to $150/month). Details can be found at the Azure MSDN Benefits site.
Note: If you already have a Git client installed, this step is not required. However, if you do not have a Git command line, then you will need to translate the labs (and demo videos) into your graphical Git tool. If you choose, you can use Visual Studio Community on Windows as a graphical tool. However, I personally recommend getting comfortable with Git from the command line.
- Download an OS specific Git client from Git download site.
- When installing on Windows, you can feel free to keep the defaults of the installer except you will want to make sure that Git is in the path if you want to use Git command line in Command Prompt or PowerShell. Or, you can choose to just use Git Bash, which is Git's command window.
If you are on a Windows OS, and do not have Visual Studio 2015 Professional or Enterprise editions, then you can download and install Visual Studio 2015 Community for free. It is not required for any of the labs, however it will be used in some of the demos. In every case, alternate approaches (browser or git command line) will be demonstrated.
Outline > Module 1: Overview of DevOps > Module Review > Module Review
[Video link: https://youtu.be/hxt68rcUZgs]
Outline > Module 1: Overview of DevOps > Supplemental Learning > External Resources
- The State of DevOps reports: 2014; 2015.
- The Velocity 2009 Presentation "10+ Deploys per Day" by John Allspaw and Paul Hammond.
- Presentation at Build 2016 by Brian Keller and Lori Lamkin from Microsoft: DevOps at Scale: A True Story.
- The Phoenix Project: A Novel about IT, DevOps and Helping Your Business Win by Gene Kim, Kevin Behr, George Spafford.
Outline > Module 2: A Unified Process Between Dev and Ops > Introduction > Module 2 Intro
[Video link: https://youtu.be/aMq5nFVV1cg]
Outline > Module 2: A Unified Process Between Dev and Ops > Introduction > Module 2 Overview
- How Agile development practices influenced DevOps and the four principles behind Agile manifesto that directly apply to DevOps.
- How source control is applied to DevOps, the importance of source control, and what needs to be source-controlled in a DevOps practice.
- The benefits of automation and how automation enables the continuous delivery of value to end users.
- The benefits of delivering small increments of value.
- How development and operations can work together and contribute to a unified DevOps process.
Outline > Module 2: A Unified Process Between Dev and Ops > Agile, Source Control, and Automation in DevOps > How Agile Software Practices Apply to DevOps
In this section, you'll learn how Agile software development has influenced DevOps. First, let's review the Agile manifesto and the principles behind the manifesto that apply directly to DevOps.
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
For more information, see Agile Manifesto.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Working software is the primary measure of progress.
[Video link: https://youtu.be/vBP6xwvfM2k]
Outline > Module 2: A Unified Process Between Dev and Ops > Agile, Source Control, and Automation in DevOps > The Importance of Source Control in DevOps
Source Control is also called Version Control. It means the management of changes to documents, computer programs, large web sites, and other collections of information. Source Control:
- Is usually supported by a tool.
- Provides ways to see differences between versions.
- Allows parallel development through merges and branches.
- Is foundational in software development, but occasionally new to operations teams.
According to the State of DevOps Report 2014, source control is one of the highest predictors of performance.
Gene Kim, one of the authors of The Phoenix Project, hypothesizes as to why:
- High numbers of failures are due to misconfiguration, instead of bad code. As a countermeasure, all production configuration should be checked into source control and used as a single source of truth.
- Source control allows anyone to recreate environments solely from what is in source control, as opposed to requiring individual or tribal knowledge.
Basically, in a DevOps practice, everything needs to be source-controlled, including:
- Source Code
- Environment definition
- Infrastructure configuration
- Deployment scripts
- Documentation
[Video link: https://youtu.be/gQahEqw99fo]
Outline > Module 2: A Unified Process Between Dev and Ops > Agile, Source Control, and Automation in DevOps > How Automation is Applied to DevOps
Automation:
- Removes manual errors from common processes.
- Enables anyone to perform operations, such as building or deploying an application, since the entire process is encapsulated in the automation tool.
- Enables speed, reliability, and consistency.
- Empowers frequent releases and self-service.
There are many tools for automation in the Operations space, such as Puppet, Chef, PowerShell DSC, Azure Resource Manager (ARM) and others. These tools enable automation for almost any task that is typically performed by ops staff, from provisioning and configuring machines to configuring networks and firewalls to monitoring (and correcting) configuration drift.
Throughout the following Dev-Test- Release pipeline, automation plays an important role to deliver value continuously.
For more information about the pipeline and the benefits of automation, watch the video below.
For more information, you can see: Azure Resource Manager: https://aka.ms/edx-dev212x-az02
[Video link: https://youtu.be/kYdySt8IK8Y]
Outline > Module 2: A Unified Process Between Dev and Ops > Agile, Source Control, and Automation in DevOps > Delivering Small Increments of Value
Agile practices prefer small, frequent releases over large, infrequent releases. In the same way, scripts and configuration changes to infrastructure should be implemented and tested in small iterations rather than large chunks. Smaller releases have several advantages:
- Less risk since the change is small.
- Rapid feedback; if something isn't working, we know early on so that we can fix it more easily.
- Confidence in what is being built; each successful iteration builds confidence that the whole product will work.
For more information about how small frequent releases can reduce the error rate and deliver higher quality product, watch the demonstration below.
[Video link: https://youtu.be/fG1AgtmA-tQ]
A build pipeline is an automated system responsible for Continuous Integration.
- It builds code, runs unit tests, creates packages, etc.
- It's generally triggered by a code check-in, or on a schedule.
Typically, a build pipeline is defined with the following components:
- Trigger
Typically, when code is checked into a branch or folder in source control, a build is automatically triggered.
Builds are typically failed if anything in the pipeline fails, alerting the team for potential issues. Mechanisms such as gated check-in prevent code from being merged into the source repo if the build fails, ensuring that the main branch is always €œclean€�.
- Tasks
The code is compiled and other tasks, such as client side minification, are executed. Unit Testing
Unit tests are performed to validate that the code is of high quality.
- Code Analysis
Static code analysis is performed and other quality metrics are gathered into a Technical Debt Management system, such as SonarQube.
- Packaging and Versioning
Assemblies are versioned and packaged so that it is ready for deployment. Sometimes the packages are uploaded to a package repository.
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Defining a Build Pipeline > Defining a Build Pipeline (Video Instruction)
[Video link: https://youtu.be/yWhZOjdhbyo]
Outline > Module 2: A Unified Process Between Dev and Ops > Hands-on Lab: Git > Learn Git
Teaching Git is beyond the scope of this course, especially since any version control system can be used effectively in a DevOps continuous delivery pipeline. However, Git is an amazingly popular version control system, and there are a number of wonderful training resources online. The following are excellent sites to learn more about Git.
- Follow the instructions on the GitHub tryGit tutorial to learn the basic commands in Git.
- Optionally, for more detailed lessons, visit Ry's Git Tutorial. The first 4 lessons are the most valuable for this course.
- Optionally, to visualize Git branching, visit the Learn Git Branching site. You can visit either the tutorial, or the blank canvas.
Note: All websites noted are hosted in an external site.
[Video link: https://youtu.be/w9uAl9HDa7I]
Outline > Module 2: A Unified Process Between Dev and Ops > Hands-on Lab: Git > Demo Git
[Video link: https://youtu.be/XPlvsdrWTwg]
[Video link: https://youtu.be/uNsmbv-JZTA]
Outline > Module 2: A Unified Process Between Dev and Ops > Module Review > Module 2 Review
What are your key takeaways from Module 2? Think about the questions you were asked in the beginning of the module:
- How has Agile influenced DevOps? What principles behind the Agile Manifesto apply
- directly to DevOps?
- Why is source control important?
- Why is automation important?
- Why are small frequent releases important?
- How can Dev and Ops work together to achieve a unified process?
Scroll down for a quick review!
[Note for Content Publisher: embed the following link]
https://sway.com/r7NcchvzoqIDpVLN
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Introduction > Module 3 Overview
[Video link: https://youtu.be/P_N5hXJ1Dj4]
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Continuous Integration, Continuous Delivery, and Continuous Testing > Continuous Integration and Continuous Delivery
Continuous Integration (CI) is the practice of merging all developer working copies to a shared code line several times a day, and validating each integration with an automated build.
In practice, CI is often defined as having a build with unit tests that executes at every commit/ check-in to version control.
Continuous Integration (CI) provides many benefits, including:
- Improving code quality based on rapid feedback
- Triggering for automated testing for every code change
- Better managing technical debt and conducting code analysis
- Reducing long, difficult and bug-inducing merges
- Increasing confidence in code long before production
Continuous Delivery is a software engineering approach in which teams produce software in short cycles, ensuring that software can be reliably released at any time.
- It aims to build, test and release software faster and more frequently.
- It reduces the cost, time, and risk of delivering changes by allowing for more incremental updates to production.
In practice, continuous delivery focuses on automated deployment pipeline. This may have one or more manual approval gates prior to reaching production.
Continuous delivery provides many benefits, including:
- It encourages Infrastructure as Code and Configuration as Code;
- It enables automated testing throughout the pipeline.
- It provides visibility and fast feedback cycles.
- It makes going to production a low stress activity.
Continuous Deployment is generally defined as a Continuous Delivery pipeline with no manual gates between initial code check-in and production.
Feature flags are commonly used in both patterns, however, they are often necessary for Continuous Deployment. Feature flags ensure that code deployed to a production environment is not necessarily released to all end users.
[Video link: https://youtu.be/vFRYaMAGL2o]
For more information, you can see:
Visual Studio Team Services: https://aka.ms/edx-dev212x-vsts
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Continuous Integration, Continuous Delivery, and Continuous Testing > Continuous Testing
Continuous testing is the execution of tests repeatedly against a code base and deployment environment.
In practice, continuous testing is the most difficult part of continuous delivery pipeline to keep up to date.
Continuous testing provides quality gates throughout the pipeline and increases confidence in code long before production.
- Unit Testing
- Integration Testing
- User Interface (UI) Testing
- Load and Performance Testing
- Manual and Exploratory Testing
For more information about the benefits of continuous testing and the types of testing, watch the video below.
[Video link: https://youtu.be/PI2utMEoBAU]
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Defining a Build Pipeline > Defining a Build Pipeline
A build pipeline is an automated system responsible for Continuous Integration.
- It builds code, runs unit tests, creates packages, etc.
- It's generally triggered by a code check-in, or on a schedule.
Typically, a build pipeline is defined with the following components:
- Trigger
Typically, when code is checked into a branch or folder in source control, a build is automatically triggered.
Builds are typically failed if anything in the pipeline fails, alerting the team for potential issues. Mechanisms such as gated check-in prevent code from being merged into the source repo if the build fails, ensuring that the main branch is always €œclean€�.
- Tasks
The code is compiled and other tasks, such as client side minification, are executed.
- Unit Testing
Unit tests are performed to validate that the code is of high quality.
- Code Analysis
Static code analysis is performed and other quality metrics are gathered into a Technical Debt Management system, such as SonarQube.
- Packaging and Versioning
Assemblies are versioned and packaged so that it is ready for deployment. Sometimes the packages are uploaded to a package repository.
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Defining a Build Pipeline > Defining a Build Pipeline (Video Instruction)
[Video link: https://youtu.be/yWhZOjdhbyo]
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Hands-on Lab: Continuous Integration > Lab Instructions
In this lab we want to set up Visual Studio Team Services to be able to continuously integrate code into the master branch of code. This means that whenever code is committed and pushed to the master branch, we want to ensure that it integrates into our code correctly to get fast feedback. To do so, we are going to be setting up a Continuous Integration build (CI) that will allow us to compile and run unit tests on our code every time a commit is pushed to Visual Studio Team Services.
Make sure you have set up your VSTS account and installed Git based on the instruction of Lab Prerequisites and Tools in Module 1.
- Import Source Code into your VSTS Account: You will connect your own Visual Studio Team Services account, download the PartsUnlimited source code, and then push it to your own Visual Studio Team Services account in order to use Build.
- Create Continuous Integration Build: You will create a build definition that will be triggered every time a commit is pushed to your repository in Visual Studio Team Services.
- Test the CI Trigger in Visual Studio Team Services: You will test the Continuous Integration build (CI) build we created by changing code in the Parts Unlimited project with Visual Studio Team Services.
Note: The task below only shows you how to import source code into your VSTS account with Git Command line. If you would like to use Visual Studio to import source code into your VSTS account, please refer to Get Started with Git and Team Services and Clone and init Git repositories.
-
Clone the repository to a local directory.
Create a parent **Working Directory **on your local file system. For instance, on Windows OS you can create the following directory:
C:\Source\ReposOpen a command line window (one that supports Git such as Git Bash) and change to the directory you created above.
Clone the repository with the following command. In the example below, the clone will be copied into a directory named HOL. Feel free to use whatever directory name you like, or leave it blank to use the default directory name:
git clone https://github.com/Microsoft/PartsUnlimited.git HOLAfter a few seconds of downloading, all of the code should now be on your local machine.
Move into the directory that was just created. In a Windows OS (and assuming you used HOL as the directory name), you can use this command:
cd HOL -
Remove the link to GitHub.
The Git repo you just downloaded currently has a remote called origin that points to the GitHub repo. Since we won't be using it any longer, we can delete the reference.
To delete the GitHub remote, use:
git remote remove origin -
Find the URL to access the VSTS Git repo
First, we need to find the URL to empty Git repository in VSTS. If you remember your account name, and the Team Project name you created, the URL to the default Git repo is easily assembled:
https://<account>.visualstudio.com\_git\<project>Alternatively, you can use a web browser to browse to your account, click into your project, and click the Code tab to get to your default Git repository:
https://<account>.visualstudio.comAdditionally, at the bottom of the web page, you will see the two commands that we will use to push the existing code to VSTS.
-
Add the link to VSTS and push your local Git repo
In the local directory from Step 3, use the following command to add VSTS as the Git remote named origin. You can either type the URL you found in Step 4, or simply copy the first command from the VSTS web page.
git remote add origin https://<account>.visualstudio.com\_git\<project>Now you can push the code, including history, to VSTS:
git push -u origin --allIf you get a dialog box that requires sign-in, enter your Microsoft account.
Congratulations, your code should now be in VSTS!
A continuous integration build will give us the ability check whether the code we checked in can compile and will successfully pass any automated tests that we have created against it.
-
Go to your account€™s homepage:
https://<account>.visualstudio.com -
Click Browse and then select your team project and click Navigate.
-
Once on the project€™s home page, click on the Build hub at the top of the page, then on All Definitions, and then on New Definition.
-
Select the Empty build definition, and then click Next.
Note: As you can see, you can now do Universal Windows Apps & Xamarin Android/IOS Builds as well as Xcode builds.
-
After clicking the Next button, select HOL Team Project, select HOL Repository, select Master as the default branch and check Continuous Integration then click Create.
Note: We may have multiple repos and branches, so we need to select the correct Repo and Branch before we can select which Solution to build.
-
After clicking the Create button, On the Build tab click the Add build step in the Build pane.
-
In the Task catalogue dialog, select the Utility page and then add a PowerShell task.
-
Still in the Task catalogue dialog, select the Test page and add a Publish Test Results task.
-
Select the Utility page again and add a Copy and Publish Build Artifacts task and then click on Close.
-
On the PowerShell Script task, click on the blue rename pencil icon and change the name of the step to dotnet restore, build, test and publish and click OK.
-
Select File Path for the Type property, enter "build.ps1" for the Script Path property and
$(BuildConfiguration) $ (build.stagingDirectory) for the Arguments property.Note: The build.ps1 script contains commands using the dotnet.exe executable used by .Net Core. The build script does the following: restore, build, test, publish, and produce an MSDeploy zip package.
[CmdletBinding()] Param( [Parameter(Mandatory=$True)] [string] $BuildConfiguration, [Parameter(Mandatory=$True)] [string] $BuildStagingDirectory ) $ErrorActionPreference = "Stop" #### Restore and build projects & dotnet restore & dotnet build .\src\PartsUnlimitedWebsite --configuration $BuildConfiguration & dotnet build .\test\PartsUnlimited.UnitTests --configuration $BuildConfiguration #### Run tests & dotnet test .\test\PartsUnlimited.UnitTests -xml testresults.xml #### Publish $publishDirectory = Join-Path $BuildStagingDirectory "Publish" $outputDirectory = Join-Path $publishDirectory "PartsUnlimited" & dotnet publish .\src\PartsUnlimitedWebsite --framework netcoreapp1.0 --output $outputDirectory --configuration $BuildConfiguration --no-build #### Package to MSDeploy format -
On the Publish Test Results task, change the Test Result Format to XUnit and the Test Results File to **/testresults.xml.
-
On the Copy Publish Artifact task, change the Copy Root property to $(build.stagingDirectory), The Contents property to
**\*.zip, The Artifact Name property to drop and the Artifact Type to Server. -
Select the Variables page and a new variable that will be used by the build.ps1 PowerShell script; BuildConfiguration with a value of release.
-
Click on the Triggers tab and verify that the Continuous integration (CI) option is selected to build the solution everytime a change is checked in. Also make sure the filter includes the appropriate branch (in this case master and Batch Changes checkbox is unchecked.
Note: To enable Continuous integration in your project, check the Continuous integration (CI) checkbox. You can select which branch you wish to monitor, as well.
-
Click Save and give the build definition a name.
We will now test the Continuous Integration build (CI) build we created in Task 2 by changing code in the Parts Unlimited project with Visual Studio Team Services.
-
Select the Code hub and then select your your repo, HOL.
Navigate to /src/PartsUnlimitedWebsite/Controllers in the HOL project, then click on the elipsis to the right of HomeController.cs and click Edit.
-
After clicking Edit, add in text (i.e. This is a test of CI) after the last Using statement. Once complete, click Commit.
-
Click Build hub. This should have triggered the build we previously created.
-
Click on the Build Number, and you should get the build in progress. Here you can also see the commands being logged to console and the current steps that the build is on.
-
Click on the Build Number on the top left and you should get a build summary similar to this, which includes test results.
Congratulations! You have completed this hands-on lab.
In this lab, you learned how to add an existing Git repo to a project in Visual Studio, create a Continuous Integration build definition to compile, test, and publish build artifacts, and the end-to-end workflow of committing code to master and automatically triggering a build.
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Hands-on Lab: Continuous Integration > Demo Videos: Migrating Code to VSTS from GitHub
[Video link: https://youtu.be/zO7ZIfFXurQ]
[Video link: https://youtu.be/MnAnKDFda4Y]
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Hands-on Lab: Continuous Integration > Demo Video: Continuous Integration
[Video link: https://youtu.be/1ZfWf0um2eo]
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Module Review > Module 3 Review
[Note for Content Publisher: embed the following link]
https://sway.com/FuihbH1Nn1xV0Epc
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Supplemental Learning > Microsoft Channel 9 Videos
For more information on Automated Testing and Continuous Integration, check out the following two videos from Microsoft Channel 9.
[Video link: https://sec.ch9.ms/ch9/ce93/b3682438-316d-4890-8bdf-4a797fe4ce93/DevOpsFundamentalsAutomatedTestingEpisode_high.mp4]
[Video link: https://sec.ch9.ms/ch9/19c6/69693b45-d2bc-4682-adca-562737d219c6/ContinuousIntegration_high.mp4]
Outline > Module 3: Continuous Integration, Continuous Delivery, and Continuous Testing > Supplemental Learning > Links and Resources
Continuous Integration by Martin Fowler.
Continuous Integration for Better Security by Dwayne Melancon.
5 Ways Continuous Integration Reduces Risk in Development by Ragnar Lönn.
Continuous Testing: What exactly is it? by Ragnar Lönn
Automated Security Testing in a Continuous Delivery Pipeline by Stephen de Vries.
From QA to Continuous Testing by Marc Hornbeek.
The Business Value of Continuous Testing by Ragnar Lönn.
The Continuous Continuousness of DevOps by Tony Bradley.
Continuous Delivery and Continuous Deployment by Vishal Sahasrabuddhe.
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Introduction > Module Overview
[Video link: https://youtu.be/gFAP9Fo0PSU]
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Configuration Management and Release Management > Configuration Management
- Configuration Management means the management of configuration of all environments for an application.
- Typically in the form of scripts that are version controlled.
- Configuration Management in the DevOps world is less formal than "traditional" configuration management.
- It emphasizes encapsulation of configuration in code over formal documentation.
- It means lighter weight, executable configurations that allow us to have configuration and environments as code.
- Infrastructure as Code: Defining your environments, to include networks, servers, and other compute resources as a text file (script or definition) that is checked into version control and is used as the base source for creating or updating those environments. For instance, adding a new server should be done by editing a text file and running the release pipeline, not by remoting into the environment and spinning one up manually.
- Configuration as Code: Defining the configuration of your servers, code and other resources as a text file (script or definition) that is checked into version control and is used as the base source for creating or updating those configurations. For instance, adding a new port to a firewall should be done by editing a text file and running the release pipeline, not by remoting into the environment and spinning one up manually.
Configuration Management provides the following benefits:
- Allowing configuration to be version controlled
- Detecting and correcting configuration drift
- Treating infrastructure as flexible resource
- Facilitating automation
- Enabling automated scale-up and scale-out
- Providing environment consistency
[Video link: https://youtu.be/D4To34eL7eE]
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Configuration Management and Release Management > Release Management
- Release management means managing what is deployed where, and how:
- What: which versions of components.
- Where: which environments are the applications deployed to.
- How: automation and scripting to configure environments and deploy applications.
- Release management in the DevOps world is lighter weight and less formal than "traditional" release management.
- It emphasizes on quick and consistent delivery over formal change control.
Release Management provides the following benefits:
- Auditing and traceability of the releases
- Automation of the release process
- Visibility of what happened in the release
- Higher quality deliveries
- Confidence through successful and consistent deliveries
[Video link: https://youtu.be/iL6GjX_eMxk]
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Configuration Management and Release Management > Defining a Deployment Pipeline
A deployment pipeline is an automated system responsible for continuous delivery.
- It deploys code to environments, enforces approval gates, and executes automated tests.
- It is generally triggered by manually or by a new build.
Typically, a deployment pipeline is defined with the following components:
- Source package
- Trigger
- Environments
- Deployment scripts and tasks
- Automated testing
- Approval gates
[Video link: https://youtu.be/uYK0Cn24Hbc]
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Monitoring and Learning > Application Performance Monitoring
- Application Performance Monitoring (APM) means monitoring and learning from "live site".
- APM tools usually provide the following information:
- Diagnostics and error reporting
- Usage patterns and trends
- Notifications on application performance
- Rules for application performance:
- Keeping the site up and highly available at all times.
- Automating scale up/down or out/in in order to save infrastructure costs and the costs of running the application.
Application monitoring:
- Identifies problems in the application.
- Dives insights into backlog from production.
- Enables hypothesis driven development.
- User telemetry helps the team to take proactive actions instead of reactive actions.
- Usage monitoring
- Availability monitoring
- Performance monitoring
- Custom telemetry
[Video link: https://youtu.be/rjOHyyifvAw]
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Hands-on Lab: Release Management > Lab Instructions
In this lab, you will set up Release Management, a feature of Visual Studio Team Services, to continuously deploy the application to an Azure Web App.
Azure Web Apps allow you to specify deployment slots. In this lab, we will use the slots to isolate changes being introduced into the environment for testing purposes. Initially the app will be deployed to a dev deployment slot. The staging slot will require an approver before the app is deployed into it. Once another approval is done on the staging slot, the app will be deployed to the production site.
- Make sure you have set up your VSTS account and installed Git based on the instruction of Lab Prerequisites and Tools in Module 1.
- Make sure you have completed the lab: Continuous Integration with Visual Studio Team Services in Module 3.
- An active Azure account to host the PartsUnlimited Website as a Web App
Note: In order to use deployment slots, you'll need to configure the Web App to use Standard or Premium App Service Plan mode. You cannot create deployment slots for Basic or Free Azure Web Apps. To learn more about deployment slots, see this article.
- Modify the CI Build to include ARM Templates The source code already defines the infrastructure required by the application in code (Infrastructure as Code). The code is json file based on the Azure Resource Manager template schema. You will use the template to deploy or update the infrastructure as part of the release.
- Create a Service Endpoint in Visual Studio Team Services to an Azure Account. In this step you'll download your Azure publish settings file and create Service Endpoint in Visual Studio Team Services for your Azure account. This will enable you to configure deployment of the PartsUnlimited Website to Azure as an Azure Web Application from Builds or Releases.
- Create a Release Pipeline for the Parts Unlimited Website. In this step, you will create a Release definition for the PartsUnlimited Website. You'll use the CI build output as the input artefact for the Release and then define how the release moves through
environmentswith approvals in between. - Trigger a Release. Once the Release Definition is set up, you will trigger a release and see the pipeline in action.
In order to deploy to Azure, you're going to specify the infrastructure that the PartsUnlimited Website requires. For example, the site requires an Azure SQL Database and an Azure Web App. Rather than create these by hand, you are going to use the Azure Resource Manager (ARM) templates that describe this infrastructure in a json file. This is good practice, since you're describing infrastructure as code.
The task that will deploy the ARM template will create the resource group if it does not exist. If the resource group does exist, then the template is used to update the existing resources.
Note: The infrastructure described in the ARM templates for this HOL will create resources that are not free. It creates an Azure Web App with 3 deployment slots. Deployment slots are only available on Standard or Premium App Service Plans. They are not available on Free or Basic plans. Once you've completed this lab, you probably want to delete the resource group in order to minimize charges to your Azure account.
Step 1. Log into your VSTS account and click on the BUILD hub.
Step 2. Click the HOL Build that you configured in the Continuous Integration HOL, and click "Edit".
Step 3. Click "+ Add build step..." and add a new "Publish Build Artifacts". Configure it as follows:
-
For
Path to Publish, click the "..." button and browse to the env/Templates folder -
For
Artifact Name, enter "ARMTemplates" -
For
Artifact Type, select "Server"
Step 4. Save the updated build definition and queue a new build by clicking the "Queue new build" button. Accept the defaults and click OK.
Note: The build process may take a while, but there is no need to await its completion before proceeding. Come back and do the last step after task 3.
Step 5. When the build has completed, verify that there are 2 folders: drop and ARMTemplates.
In order to interact with Azure, you'll need to create a Service Endpoint in VSTS. This Endpoint includes the authentication information required to deploy to Azure.
Note: Deploying ARM Templates to Azure from Release Management requires an organizational account or a Service Principal. MSA Accounts and certificate-based connections are not supported. For this HOL, you will use an organizational account, but you can create a Service Principal if you wish to.
Step 1. Create an organizational account in Azure 1. Create a user in the Azure Active Directory from the old Azure portal (https://manage.windowsazure.com). If you do not have a custom domain, then use the onmicrosoft.com domain (the default domain). The user should be something like testuser@myazure.onmicrosoft.com 2. After adding the account, the following two things need to be done to use the account during a VSTS release: * Add the Active Directory account to the co-administrators in the subscription. Go to the Settings hub (click on the Gear icon in the left-hand main menu) and then click on administrators and add the account as a co-admin. * Login to the portal with this Active Directory account (e.g. testuser@myazure.onmicrosoft.com, and change the password. Initially a temporary password is created and that needs to be changed at the first login.
Step 2. Create an Azure Service Endpoint in Visual Studio Team Services 1. Log in to your VSTS account. 2. Open the project administration page by clicking the gear icon in the upper right.
-
Click on the Services tab
-
Click on "New Service Endpoint" and select Azure Resource Manager from the list
-
Fill out the form below to create a Service Principal. Click on "Verify connection" button to check that all details were filed in correctly and then click on "OK" button.
-
You should see a new Service Endpoint. You can close the project administration page.
Now that you have an Azure Service Endpoint to deploy to, and a package to deploy (the output from your build), you can create a Release Definition. The Release Definition defines how your application moves through various Environments, including Tasks to update infrastructure, deploy your application, run scripts and run tests. You can also configure incoming (pre) or outgoing (post) approvals for each Environment.
An Environment is simply a logical grouping of tasks - it may or may not correspond to a set of machines. For this Release Definition, you will create three environments: Dev, Staging and Production.
The infrastructure required for all three environments is described in an ARM Template. The ARM Template will be invoked during the deployment in the Dev Environment before deploying the website to Dev. It will not be necessary to run any infrastructure tasks during Staging or Production deployments in this case.
Step 1. Create a Release Definition to Deploy Infrastructure and Deploy to Dev.
-
In VSTS, click on Releases. Then click on the "+ New definition" button to create a new definition. This will launch a wizard prompting you to select a deployment template. Click on "Empty" to start with an empty release and click "Next". For this lab you can simply use the defaults on the next page of the wizard and click "Create".
-
The template has created a single Environment (called Environment 1).
-
Enter "PartsUnlimited" into the name field at the top to name this Release Definition.
-
Before completing the "Azure Web App Deployment" task, you'll need to configure the source package. Click on the "Artifacts" link.
-
If build definition did not get linked automatically then click on "Link to an artifact source" link, otherwise check that it has the correct settings.
-
You'll now link this Release Definition to the CI build. Select the Project and Build from the drop downs and click "Link".
Note: It is possible to Link other package sources, but you only need the CI build for this Release.
-
Click on the Environments link to go back to the Environments page.
-
Click the name label "Environment 1" and change the name to "Dev".
-
Click on the "+ Add tasks" button to add a task for this environment. In the "Deploy" group, click the "Add" button next to "Azure Resource Group Deployment" to add the task. Close the "Task catalogue" dialog.
-
Click on the "Azure Resource Group Deployment" task. Configure it as follows:
Azure Connection Type: Azure Resource ManagerAzure RM Subscription: select the Azure subscription endpoint that you created in Task 2Action: select "Create or Update Resource Group"Resource Group: enter $(ResourceGroupName) into the box, you will create a variable named this shortly.Location: select an Azure locationTemplate: click the "..." button and browse to the FullEnvironmentSetupMerged.json file in the ARMTemplates folder.
Template Parameters: click the "..." button and browse to the FullEnvironmentSetupMerged.param.json file in the ARMTemplates folder.
Override Template Parameters: Enter the following in a single line (shown split here for convenience):
-WebsiteName
You will shortly define the values for each parameter, like $(ServerName), in the Environment variables.
Note: If you open the FullEnvironmentSetupMerged.param.json file, you will see empty placeholders for these parameters. You could hard code values in the file instead of specifying them as "overrides". Either way is valid. If you do specify values in the params file, remember that in order to change values, you would have to edit the file, commit and create a new build in order for the Release to have access the new values.
- Make sure the `Output -> Resource Group` parameter is empty. It is not required for this release.
-
Click on the ellipsis (...) button next to the Environment and select "Configure variables..."
-
Create the following variables, adding values too.
- WebsiteName - Name of the website in Azure
- ServerName - Prefix for the name of the database servers. Will have
-devor-stageadded for dev/staging - HostingPlan - Name of the hosting plan for the website
- StorageAccountName - Storage account name prefix. Will have
-devor-stageadded for dev/staging - ContainerName - Container name prefix. Will have
-devor-stageadded for dev/staging - AdminPassword - Admin password for production database server
- AdminTestPassword - Admin password for dev and staging database servers
- ResourceGroupName - Name of the Resource Group.
Note: Use unique values for your variables by adding something custom at the end like your initials. Example for WebsiteName : pudncorejstr
Note: You can hide passwords and other sensitive fields by clicking the padlock icon to the right of the value text box.
-
Save the definition.
Step 2. Test the ARM Template Deployment
Before moving on, it is a good idea to test the template so far.
-
Click on "+ Release" in the toolbar and select "Create Release" to start a new release.
-
Select the latest build from the drop-down, and then select "Dev" as the target environment. Click "Create" to start the release.
-
Click the "Release-x" link to open the release.
-
Click on the Logs link to open and monitor the deployment logs.
-
You should see a successful release after a few minutes.
-
If you log into the Azure Portal, you will see the Resource Group has been created.
Step 3. Add Web Deployment Tasks to Deploy the Web App
Now that the infrastructure deployment is configured, you can add a task to deploy the web app to Dev.
-
Click on the Dev environment in the Release Definition. Then click "+ Add tasks".
-
Select the "Deploy" group in the left and click the add button next to "AzureRM Web App Deployment" to add the task. Close the task selector dialog.
-
Click on the "AzureRM Web App Deployment" Task.
-
Select the Azure Service Endpoint you created earlier in the AzureRM Subscription drop down.
-
For Web App Name, enter the $(
WebsiteName) to use a variable. You defined this variable earlier when deploying the ARM Template. You will shortly "promote" it to a Release variable so that it can be used in all Environments in the Release. -
Check the Deploy to Slot check box
-
Enter $(
ResourceGroupName) into the Resource Group Box. -
Enter "dev" for the Slot. This will deploy the site to the "dev" deployment slot. This allows you to deploy the site to an Azure deployment slot without affecting the Production site.
-
Tick "Take App Offline". This stops the website for deployment period and takes it back online afterwards. This is required because sites receive requests all the time causing files to lock down (i.e. making them unmodifiable).
-
Click the ellipsis (...) button, next to the Package box, to set the Web Deploy Package location. Browse to the PartsUnlimitedWebsite.zip file and click OK.
-
Clear the "Additional Arguments" parameter. The ARM template you deployed has already configured all the slot-specific app settings and connection strings.
-
The Task should look like this:
Note: It is a good practice to run smoke tests to validate the website after deployment, or to run load tests. The code-base you are using does not have any such tests defined. You can also run quick cloud-performance tests to validate that the site is up and running. For more information on quick load tests, see this video from around the 6 minute mark.
-
Promote the WebSite Environment variables to a Release Variables
- Click on the "Dev" environment, click the ellipsis (...) button select "Configure Variables".
- Make a note of the
WebsiteNameandResourceGroupNamevariables' values and delete them from this list. Click OK. - Click on "Variables" to open the Release variables. These are "global" variables that any Environment can use.
- Enter "WebsiteName" for the name and enter the value for the Website in Azure. Enter "ResourceGroupName" for the name and enter the value for the Resource group in Azure.
-
Click Save to save the Release Definition.
Step 4. Test the Dev Environment You will shortly clone the Dev Environment into both Staging and Prod environments. However, before you do that it's a good idea to test that the Dev Environment is correctly configured by creating a new Release.
-
Click on the "+ Release" button and select Create Release.
-
You can enter a Release Description if you want to.
-
Select the latest build from the HOL Build drop down and click on "Create".
-
Click the Release link to open the Release.
-
Click on the Logs link to open the deployment logs.
-
Once the deployment completes, you can check that the site was in fact deployed successfully by navigating to the site url.
Since you deployed to the dev slot, you will need to navigate to
http://{siteName}-dev.azurewebsites.netwhere siteName is the name of your Web App in Azure.By default you will only receive email notifications on failed release. This can be changed in settings for each environment. Click the ellipsis (...) on the Dev Environment card and select "Assign approvers..". Navigate to "General tab" and set the desired behavior.
Step 5. Clone the Dev environment to Staging and Production
Now that you have verified that the Dev Environment is configured correctly, you can clone it to Staging and Production.
-
Click on the PartsUnlimited link and then the Edit link to open the Release Definition.
Note: It is possible to change the definition for a Release without changing the Release Definition (i.e. the Release is an instance of the Release Definition that you can edit). You want to make sure that you are editing the Release Definition, not a Release.
-
Click the ellipsis (...) on the Dev Environment card and select "Clone environment".
-
In the Dev Environment, you did not define any approvers. For Staging, however, you should configure approvers. In "Pre-deployment approval" section choose people who will approve deployments to staging environment and click "Create".
-
A new Environment is created. Enter "Staging" for the name.
-
Delete the "Azure Resource Group Deployment" task. This is not required in this Environment since the ARM template deployed the infrastructure for all 3 environments.
-
Click the ellipsis (...) on the Staging Environment card and select "Configure variables".
-
Delete all the variables. These are used by the "Azure Resource Group Deployment" task which you just deleted, so they are not necessary in this Environment.
-
On the Azure Web App Deployment task, set the Slot to
staging.
**Note:** If you had environment-specific variables, you would be able to set Staging-specific values. It is not necessary in this case.
- When we cloned dev to staging we set one person for staging's pre-approvals. We can adjust it even further by clicking ellipsis (...) on the Staging Environment card and select "Assign approvers...". For this HOL, you can be both incoming and the outgoing approver.
- In this case, you want to pause the deployment coming in. This ensures that if someone is testing in the Staging environment, they don't suddenly get a new build unexpectedly.
- Configure approvers for the Staging environment.
**Pre-deployment approvers** must approve a deployment coming into the environment. The deployment will stop and wait before executing any tasks in the environment until approval is granted.
**Post-deployment approvers** approve deployments so that the next Environment can begin. They act as sign-off for the current environment.
**Approvers** can be individuals or groups.
-
Clone the Staging environment to Production.
- Untick "Deploy to Slot" (i.e. the site will be deployed to the production slot).
- Update the approvers - again, you can be both approvers.
-
Save the Release Definition.
Step 6. Configure Continuous Deployment for this Release Definition
-
Click on the Triggers link of the Release Definition.
-
For "Release trigger" pick "Continuous Deployment" and set trigger to the build definition created before.
Selecting the build as the trigger means that any time the artifact build completes, a new release will automatically start using the latest build.
-
Set "Environment triggers" to the following settings:
- Deployment to "Dev" environment should be triggered after release is created.
- Deployment to "Staging" can be triggered on successful deployment to "Dev".
- Deployment to "Production" can be triggered on successful deployment to "Staging".
Note: Since the incoming build for this release is a CI build, you probably don't want to deploy the build all the way to Production. Setting the Release to stop at Dev means that you will need to create a new Release with Production as the target environment if you want to deploy to Production. This is of course configurable according to your own preference.
Task 5: Create a Release
Now that you have configured the Release Pipeline, you are ready to trigger a complete release.
-
Click on "+ Release" to create a new Release.
-
Select the latest build, click Create.
Note: You can adjust whether to deploy this release to a particular environment.
-
Once the Dev stage has completed deployment, you will see a notification that an approval is pending (you will also have received an email notification if you ticked "Send an email notification to the approver whom the approval is pending on" option in settings for this environment). Check the dev slot of the PartsUnlimited site in Azure to ensure that the Dev environment is good, and then click Approve.
-
You can also see pending approvals in the overview pane:
-
Optionally enter a comment and click the Approve button.
-
This will trigger the release into the Staging environment.
Note: You can reassign the approval if required.
-
Once the Staging deployment has completed, you will need to approve that staging is OK.
-
This will then trigger the pre-approval for Production. Once you've approved that, deployment into the Production environment will begin.
-
To see all your releases and where they are in their respective pipelines, click on All Releases and then click the Overview link.
Congratulations! You have completed this hands-on lab!
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Hands-on Lab: Release Management > Demos
[Video link: https://youtu.be/0w-qHwAjYm0]
[Video link: https://youtu.be/xUsiIzF6Oe4]
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Module Review > Module Review
[Note for Content Publisher: embed the following link]
https://sway.com/skK5M8Yij5sLHSyd
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Supplemental Learning > Microsoft Channel 9 videos
For more information on Release Management, Configuration Management, and Application Performance Monitoring, check out the following videos from Microsoft Channel 9.
[Video link: https://sec.ch9.ms/ch9/bec4/d5c459b6-0e61-47c6-9c8b-0c6a6ad8bec4/DevOpsFundamentalsContinuousDeployment_high.mp4]
[Video link: https://sec.ch9.ms/ch9/5aab/6b5d0819-fa03-4792-bd50-84d2c3845aab/ConfigurationManagement_high.mp4]
[Video link: https://sec.ch9.ms/ch9/09fe/7c2d6081-bd60-4a17-bf15-8c128b5009fe/ApplicationPerformanceMonitoring_high.mp4]
Outline > Module 4: Configuration Management, Release Management and Monitoring & Learning > Supplemental Learning > Links to External Resources
Infrastructure-as-code, new rules for the old game by JP Morgenthal.
Meet Infrastructure as Code by Chris Riley.
If you "code" your apps, why do you still "configure" your IT infrastructure? by Ranga Rajagopalan.
Automation, Provisioning and Configuration Management with PUPPET by Sudhi Seshachala.
Automation, Provisioning & Configuration Management (CHEF) by Sudhi Seshachala.
Release Management, a catalyst for DevOps by Salaam Khurram.
Service Monitoring and Diagnostics by Victor Mushkatin.
5 ways APM can solve your DevOps worries by Payal Chakravarty.
Can your DevOps and APM initiatives increase customer loyalty? by Peter Waterhouse.
Outline > Final Exam > Post-course Survey > Post-course survey
Please take a few minutes to complete this brief survey about your experience with this course. The results of this survey will be used to help us make improvements to this course as well as others.
If the survey is not displayed in your browser you can complete it at https://mslexsurveys.azurewebsites.net/survey/607830. Thank you for your feedback. Your opinion counts!
Post-course Survey
