Simplify DevOps with Visual Studio Team Services
Visual Studio Team Services (VSTS) is a DevOps tool designed to eliminate the confusion of having to use disparate tools throughout the IT department to manage project backlog, development, and deployment. The usage of a single tool streamlines the development process for business, developers, testers, and infrastructure team. All of IT has the same application and a single source of truth regarding what is being worked on, in development, in testing, and what is next to be deployed.
In a typical IT department, the business might be using JIRA to manage the backlog and tasks, Bitbucket/GIT to manage source control, and Jenkins to do continuous builds. This leads to different teams needing to figure out how to best manage the process of moving data across different software, managing user access, licensing costs for each piece of software, and ownership of that piece of software.
Since VSTS offers all these services in a single package, only a single license per developer, a single owner, and single permission needs to be set up in the company. With everyone using the same software, the business, development, and deployment process is significantly streamlined.
Let’s look at how easy it is to use VSTS.
VSTS is designed to be able to handle backlog management whether your team uses Agile, Scrum or CMMI (Capability Maturity Model Integration) process. This flexibility allows the business to use the terminology and processes that they are accustomed to using.
VSTS makes sprint and resource management extremely easy by making it uncomplicated to add and manage resource availability and activity type per sprint. In the image below, these developers are assigned activity types and available hours per day for that Sprint 1. Company holiday closings can easily be tracked as well using Team Days Off. This is accomplished on a single screen where other applications require you to go into each resource’s calendar.
As soon as the sprint begins, you can view the team progress via a Kanban chart. You can see the team’s Cumulative Flow in the top right corner of your board. Of course, you can map and/or rename any swim lane to match your company’s terminology.
Once the team begins development, the team uses VSTS to manage code changes without using a different tool than business. This makes it easy to add development progress notifications to the business without the developer having to update several applications to keep everyone in sync.
Source Control Management
In enterprise and open source environments, developers are used to going through a 3-step Git workflow process of first forking the code repository and cloning it locally, developing their assigned story or task, then requesting a Pull Request for code review and merging the completed code into a master or integration branch. This same Git workflow is made easy by VSTS visual tools.
Forking the Repository
Once a developer has logged into VSTS Project, they are offered the option to fork the repository via VSTS project management screen. In the image below, the developer has the option to either fork the project or clone the project.
Upon choosing to fork the project, the developer is given a fork dialog already configured with the most common naming convention. In the dialog image below, notice that the new repository name has the developer’s name appended. This allows for a quick visual indicator on the repository listing screen as to who owns that repository. A side effect of adding the developer’s name is a guaranteed uniqueness of each code repository name. If the naming scheme does not fit your organization naming convention, it can be changed by overriding the default repository name.
Because the code has been forked into a local repository, the developer can accomplish their work with the full capabilities of git source control. They can add, commit, revert, and squash their changes without worrying about affecting other developers on the same project.
Cloning the Repository
The next step in the Git workflow is cloning the newly forked repository so that the developer can begin their work. VSTS makes this process easy by giving the developer two cloning options of either SSH/HTTPS via command line or directly in Visual Studio if using Microsoft’s famous IDE. If the developer is used to using Git or Bitbucket, they can continue using the SSH command line cloning commands they are well versed in. In the image below, you can see the dialog presented with the different cloning options.
Once the developer has developed, committed, and pushed their code, it is time to request a Pull Request. VSTS makes the process easy by allowing the user to request a pull request via the VSTS New Pull Request button on the Code View web or the VSTS home page. Organization code review policies are automatically enforced for each pull request. For example, many organizations have the minimum requirement that the code must build correctly and that at least another developer has conducted a code review. All these features are supported via VSTS Branch Policies. In the branch policies setup window below, the branch can be set up to always require a successful new build and that at least one developer has approved the code. Of course, as each step is accomplished, the developer is notified as to the status of their pull request.
Automated Builds Management
VSTS has extensive support for automated build and deployment management as part of the Continuous Integration/Continuous Deployment DevOps process. With its extensive gating features, continuous build support, and deployment configurations, every developer can be part of the development process.
VSTS allows the team to set up build definitions and deployment plans which inform VSTS the steps needed when a story is completed and checked into a branch.
For example, the diagram below shows a configuration of how this code is to be handled by VSTS. When this repository’s new changes are approved via a Pull Request, the code is automatically built and pushed to dev. From dev, the same code is readied for deployment to staging and test environments. Because the environment servers, names, login information, etc. is locked away into the definition, any role assigned developer or QA person can approve the changes and deploy the code without needing an OPS person to log into a server and manually deploy the changes. This ensures that the latest code is immediately available for the QA team, who no longer needs to wait for a free DevOps person to build and deploy the code before they can begin testing.
If the build fails, the developer who wrote the code is automatically notified and their code is rejected from merging into the Master/Integration branch. This safeguard saves a lot of time from DevOps, as they are sure that any code they receive has passed.
Another benefit to VSTS managing builds and deployments is that developers don’t need or have permissions to each environment. Only the VSTS program is given permission to access these servers. This greatly reduces security concerns as developer credentials and roles don’t need to be audited on a regular basis as developers move from project to project or leave the company.