DevOps Practices

If you are in the Information Technology business and you haven’t read “The Phoenix Project”, then you are really missing out. Written in the style of “The Goal”, it’s a story about a business that has been trying to get this massive project out released to its users. The central character has been handed this disaster and, with the help of others, he breaks tradition to deliver software with a more modern approach. As he gets his Operations team to work with Development (and even Business), he’s able to step you through how they mature their DevOps practices.

There’s no doubt that DevOps is the marketing term du-jour right now and it means whatever that specific vendor wants it to mean. Some cynics will tell you that after so many missteps, Agile needed a new brand. Many tooling vendors like Chef or Puppet will tell you that DevOps is just about automating environment provisioning and configuration. At Microsoft, we have so many of our own solutions and an extensive network of partners that we naturally take a more holistic view. I tend to agree with those that see DevOps as a stage in our industry’s maturation.

For me, DevOps really took hold when the cloud showed us that we could spin up an entire set of pre-configured servers in just a couple minutes. No one would use the cloud if you went to a vendor’s web site and put in a request for a set of servers that would take two weeks to provision – and yet that’s many weeks or months faster than most IT organizations deliver even today. This revelation of a better world made us start to question a lot of things.

·      Release cadence? Near the end of “The Phoenix Project”, the main character’s mentor challenges him to release his project 10 times a day! This is a project that they haven’t been able to successfully deploy even once. Netflix is probably the most famous for this mindset. They release multiple times a day to a wide array of platforms and devices. If you have to release every day, it forces you to re-think where you are spending your time.

·      Infrastructure-as-code? I’ve never held a job in Operations and I don’t know if that impacts my thinking, but this is the DevOps practice that excites me the most. By defining all of the aspects of my servers, operating systems, networks, and more as code, I can automate it. Most obviously, this allows me to provision and configure environments quickly, but there’s much more to it than speed. With this automation, I no longer worry about a sprawling server image library. I can programmatically put all of the pieces together in any configuration I want. I can ensure that my configuration doesn’t “drift” by re-applying my configuration as needed or on a regular cadence.

·      Automated deployment? Many development teams have automated their application installation for years. At my previous job, we automated a lengthy set of manual deployment instructions of our web services into an .MSI that we could deploy in a fraction of the time with exponentially more confidence that we didn’t miss a critical step. (There’s nothing worse than a production rollback due to failed deployment steps.) This practice isn’t new, but now we could attach this automated deployment to our automated provisioning. This created a release pipeline that we could orchestrate, measure – and finally manage.

·      Automated testing? The final manual step in any application deployment is testing. Once you have automated everything else, your manual testing efforts become this obvious bottleneck that limits your ability to release with any speed or agility. (In addition to slow execution, manual testing is rife with problems. Inconsistent test results are common and rarely is any analysis done that helps a developer reproduce or identify the problem.) The solution is “simple” – automate your testing. Start by writing unit tests that run after every build. Then start automating your functional tests. Don’t forget about your performance and load tests too.

·      Close the loop? Do I automate tests for everything? Couldn’t those test runs take forever? Unit tests run as part of the build and they run fast so the bottleneck will be around your functional and performance tests. Now that you’ve finally released your Phoenix Project to production, you have all the data you need to help you understand what to test. Automate the tests that ensure your users still have a great experience with the features that they use most. Automate the tests that ensure your business success (e.g. the shopping cart) and de-prioritize the tests that provide little risk to your business.

·      Short-lived Dev/Test? When you combine infrastructure-as-code, automated deployment, and automated testing, you have matured to a point where you can start to add value beyond speed. One example is the money you can save by soaking up resources with your dev/test environments. Imagine you are a developer that is asked to fix a bug. First, you write the unit test that will verify your bug is fixed. Then, you write the code to fix the bug. You check in the code and a build is kicked off. This build server was spun up dynamically just for the duration of your build. After it compiles successfully, your bank of unit tests verify that the bug is fixed and nothing else is inadvertently broken. Your release pipeline then provisions an environment to deploy your new version of the app. We then run all of our automated tests. If these pass, we promote the app to production state. (With Azure Web Apps, we can literally make this exact tested environment be production.) Now, we can safely tear down the dev/test environment. The kicker: all of that could have happened in a span of minutes.

·      Think small? But, Jeff, what about the time it takes to clarify requirements and actually write the code? You can’t release a project that contains hundreds of requirements many times a day, but you might be able to release a project that contained just one requirement or bug fix if the rest of your process is automated. Use feature flags to hide larger code efforts, but get them deployed. Windows 8 taught us a lot and getting user feedback early was one of those lessons. With Windows 10, we make certain features available to early adopters through a combination of feature flags and build “rings”.

·      And more? Developers continue to explore this space in an effort to spend our time and resources where they should be – on providing business value. Can microservice architectures help us be smarter about breaking up business logic? Git has made branching easy, but some teams are moving to a single branch model to avoid the time and problems that come from merging. Can we build an Enterprise API Economy that enables us to write less code and compose pieces together at the speed of business?

If your organization is like many of the enterprises I talk to, the cultural implications of moving this fast become the biggest obstacle. While I’d love to sell you a tool like Team Services that would make all of this work, the most successful teams focus on the people to make this first step in a Digital Transformation. If you live near St. Louis and you want to learn more about DevOps, register now for the Silver Linings conference. Specifically, check out sessions from some of the leading DevOps consultants like Polaris Solutions that can help you make the culture change that is so critical to success.