Unicorn Series – Development Environment

Headline: An Integrated Software Development Environment is easily enabled with the capable tools today. We leverage those capabilities and focus our attention on adding value to the business, not on playing with technology.

This post in the Unicorn Series focuses on having an effective Integrated Software Development Environment.

Overview

The primary technologies supporting our software development efforts are:

• Microsoft Visual Studio Enterprise
• Microsoft Azure DevOps
• Microsoft Azure

In 2018 I attended a presentation that spoke to the “best tools” to use deployment, build, error tracking… 13 areas in all. After the presentation I was speaking with a fellow attendee, and they were very excited. They were using almost all the same tools. I asked how large the team was that maintained these tools. The number of people that maintained and integrated all those tools in their organization was larger than our entire development team! I then showed him our application on my phone. I think I ruined their night. They asked how many people we had maintaining our environment. “From our company? None. I’m not sure how many people at Microsoft are maintaining it for us.”

Focus on adding value to the business, not playing with technology.

Cloud Based

Each developer has a computer but there are no servers in our environment and no “Virtual Machines” (VMs). In other words, the only machine I log into is my computer. We leverage Platform as a Service (PaaS) in Azure while using VMs would fall under Infrastructure as a Service (IaaS) (image adapted from https://robertgreiner.com/windows-azure-iaas-paas-saas-overview/):

The main services that we use are:

• App Services – web applications, and each has a staging and production slot
• Function Apps – small worker applications
• SQL Databases – relational databases
• Key Vaults – store passwords in a secure manner
• Storage Accounts – store files
• Application Insights – track failed requests
• Traffic Manager – send user to the fastest working web endpoint

We have half a dozen servers located around the globe which is why we have the Traffic Manager to route users to the closest server for performance. And if a server is down, it is taken out of the possible servers to be routed to.

Key Features We Utilize

I will not try to document all the features here but rather describe key characteristics of the environment as well as best practices we utilize. I’ll basically follow the trail from idea, to code, to deployment.

Azure DevOps Scrum Template – We use the work items Features, Product Backlog Items (PBIs), Tasks, and Bugs. We tried to use the Epic level but that is one too many levels for our project.

Visual Studio Enterprise – The Enterprise edition is needed by our team primarily due to the more advanced testing capabilities.

Git for Version Control – We switched to Git rather than Team Foundation Version Control in October 2017. I’m so glad Microsoft bought GitHub.

Pull Requests (PRs) – This involves a lot of moving pieces.

• Feature Branches – we create feature branches to work in. Since Azure DevOps does not properly handle branch creators, we create branches with the author (initials), work item, and topic. For example, I might be working on adding a save dialog for work item 15201 thus I would create a branch feature/kz/15201-save-dialog.
• Associate Commits to Work Items – when committing we always associate it to a work item for traceability.
• The Pull Request – We require at least one reviewer that has not done work in the feature branch. That PR also has key items to review such as Security.
• Approval after Continuous Integration (CI) Build Works – we continuously build the main branch along with all the feature branches. We approve when we know the CI build along with the unit tests all worked.

Now we have approved a pull request, closed the work item, and have a successful build of the main branch.

Continuous Deployment – We have a dev/testing environment to which each build from the main branch is deployed. We do not deploy feature branches, just build them. Now the Product Manager can verify that the features work as expected.

Deployment (to production) – Our Azure DevOps release pipeline that deploys to production will first update the databases. We are careful not to have breaking changes. One time we had a breaking change that required careful orchestration. Next, we deploy the code to the staging slot for each server. When servers are idle for more than 30 minutes, we then will swap the staging and production slots. As a result of this architecture, we have had 100% uptime for more than 3 years.

Utilizing the Traffic Manager along with staging and production slots for deployment have allowed us to have 100% uptime for the past 3 years.

Results

Our focus is on adding value to the business, not playing with technology for technology’s sake. This has yielded business results.

• As of the time of this writing, there have been 62 Customer Reported Bugs (CRBs) since 19 June 2016. That is 62 Customer Reported Bugs in 100 months or less than 1 bug per month. (Quality, Lower Cost)
• The overall uptime has been well over 90% with 100% uptime in the last three years. (Quality)
• We have no dedicated configuration management or DevOps team. (Lower Costs, Business Focus)
• We have no dedicated testing team. (Lower Cost)

Summary

Leveraging today’s technology for an integrated development environment allows us to focus on the business. We chose tools that were designed to work seamlessly together to make our work efficient.

Footnote

I worked in many organizations that took the attitude, “We are special. Such tools won’t meet our needs. We need to customize them.” I’ll give an example without naming the company. The company started using TFS (Team Foundation Service) on premises and discovered that you could customize your template. Well, with each update you now have to deal with changes they might make that would break your customizations. And I don’t mean a few customizations, I mean 226! I took one custom field that everyone said was vital. Out of over 6000 work items only 2 had that field filled out! That’s 0.03%! We did a review, and it turns out our process wasn’t special, unless special means lacking. We benefitted from using the standard practices and reduced the customizations to 17!

Today we have zero customizations. Actually, I don’t even know if you can do that anymore.