DevOps on Windows’ Greatest Hits

We’ve only been actively publishing articles here at DevOps on Windows for about 4 months now, but hopefully it’s not too soon for a greatest hits article. We’ve had a great time writing all of our articles, but we wanted to take a moment to reflect on some older articles you may find helpful, and to sort of tie things back to our central theme here.

As mentioned on our About page, our core message here at DevOps on Windows is that software should be simple to operate. It’s a pretty broad statement, but as you may have noticed as you read our articles, there are several things you can do to works towards achieving this goal.

Consistency is probably one of the first and most important things you can do to reduce the operational complexity of your software. We talked about consistency with your platform in “Choose a Platform and Stick With It“, and we talked about consistency with your deployments in “Your Deployments Need Consistency, Not Automation“. Having consistent, repeatable processes should be a prerequisite to any automation initiatives.

While it’s not a panacea, implementing XCOPY deployments like we talked about in “Learning to Love XCOPY Deployment” can be a great way to help ensure consistent deployment processes across your different classes of applications: GUIs, Windows Services, and console based applications.

Next, as we’ve said before, many of the difficulties encountered during deployment relate to configuration — changing the DEV database connection string to the PROD one, ensuring that the correct IP addresses are being used for web services, etc. Many times, attempts at automating the management of application configuration data just ends up moving the problem instead of solving it. Making the application configuration “a problem for operations to solve” just drives the wedge dividing development and operations even deeper.

In “Configuration Done Right” we talk about a configuration service implemented as a context-aware key-value store as a way to solve “the configuration problem”. Then in “Avoid Structured Configuration Data” we talked about ways to “shape” your configuration data to maximize the configuration service’s flexibility going forward.

As they say, a house is only good as a foundation. If your production environment is the house your users live in, then your software build process is the foundation that the production environment is built on. By having a consistent, repeatable software build process for your applications you can greatly streamline the process of getting application binaries from development to operations for release into production.

We talked about some build system best practices in “What Makes a Build System“. Then to go a step further we talked about some more best practices regarding continuous integration servers in “Build Server Best Practices“. And as you work on improving your build process, you may also find your overall release branching/tagging process could use some work to make your developers’ lives easier when it comes to releasing software. In “Branch for Release (and nothing else)” we talk about our preferred branching pattern that can help with this.

Some of people, especially the more operations/production environment minded folk may wonder what the hell a build system has to do with production. Just remember our first point: consistency. As we make each step of the application/release life cycle consistent, we get a little more efficient each step of the way which makes the entire process flow that much more smoothly in the end and builds towards of our goal of making software simple to operate.

Speaking of software development, in “Apply Development Best Practices to Your Practice” we talked about ways you could apply some standard software development practices to your overall DevOps practices.

Ultimately, all of this “DevOps stuff” tends to have you moving towards Continuous Delivery. As your release events increase in frequency, inevitably you’ll force yourself to improve your overall process which all in all will reduce the risk and effort involved in your software release process. In “Baby Steps Towards Continuous Deployment” we talked about one path towards this Continuous Delivery goal.

Another theme that you may have noticed by now, but that we haven’t explicitly mentioned yet is that your entire release management process – from source control, to build systems, to release tracking, to configuration, and finally to deployment – should be a built on a series of relatively simple, standard, and lightweight components.

Each of the components of your application life cycle management should build on each other, but none of them should totally depend on each other. If any one component fails or is unavailable, you should still be able to compile, stage, configure, deploy, and actually run your applications. But by putting these components together, you create a process that is greater than the sum of its parts; much like how combining development and operations into DevOps enables your organization to rapidly produce quality software and services.

You may have noticed we haven’t really touched on deployment automation solutions much. That is deliberate! In our experience, if you tackle some of these deeper issues first, your lack of deployment automation becomes a much smaller problem.

Thanks for reading! We hope you’ve enjoyed our articles so far, and we hope you’ll stay tuned as we have plenty more to come!