Without automation, there would be no devops. How organizations implement automation—from continuous delivery to automated testing to release pipelines—differs wildly, but the fundamental divergence in approaches begins at the operating system. When it comes to Windows vs. Linux, devops is a bit different.
Not every devops tool is created equal when it comes to managing a Linux or Windows system. Yet, it’s up to us as devops practitioners to manage these distinct architectures as if they were one. That is the goal. For Windows organizations used to working the Windows way, this can be a bit challenging.
Here, we provide a look at key devops tools for better managing Windows fleets. Whether you’re a Windows shop or an organization that runs critical services on both Linux and Windows, these tools—ranging from integrated development environments to test frameworks—will prove invaluable in embracing devops for Windows machines.
Code IDEs
Devops automation isn’t achieved by managing environments with a GUI; code is what makes automation happen. It is the integral engine of the software release process. Developers and devops engineers alike need a development environment that allows them to edit automation scripts quickly and efficiently in their language of choice.
Visual Studio. Visual Studio is the Cadillac of coding for Windows and, increasingly, other platforms. Visual Studio natively supports C, C++, VB.Net, C#, and F#. Other languages are supported via language services.
Visual Studio can be expensive, ranging from $500 to $1,200 if purchased alone, or it can be obtained through numerous other Microsoft programs. It offers many integration points with a wide range of services, such as Azure, AWS, and Hyper-V—all of which will be valuable to devops engineers. However, Visual Studio is much more than an IDE, and as such, it is a complex product with lots of bells and whistles. For a developer, Visual Studio may be a necessity, but for a devops professional, the complexity may not make it the right choice. Luckily, there are a wealth of options to choose from.
Visual Studio Code. Visual Studio Code is a great IDE. It’s lightweight and simple compared to Visual Studio, and it supports dozens of languages out of the box. Visual Studio Code is available on MacOS, Windows, and Linux, and it offers many of the same features that Visual Studio does, like plugin support, snippets, source control integration, and more.
Visual Studio Code is free and open source, which means teams can have input into the future of the product.
Since Visual Studio Code is a new IDE, many features that one might expect in a mature IDE are not there yet, but it is under active development, and updates are frequently released. If you’re looking for a lightweight, platform-agnostic IDE without all the bells and whistles, Visual Studio Code is an excellent choice.
Sapien’s PowerShell Studio. When it comes to Windows and devops, it’s impossible to get away from PowerShell. PowerShell is included with all recent Windows operating systems and is ubiquitous among Windows devops organizations. As such, it’s only fitting to consider including a PowerShell-only IDE in your toolbox.
Sapien’s PowerShell Studio is a mature IDE available only on Windows. It can be thought of as the Visual Studio for PowerShell developers. Through its vast set of features and core focus on PowerShell, it provides an IDE that understands the PowerShell language and PowerShell developers. For all these features, though, it is not a free product like Visual Studio Code is. Expect to pay a few hundred dollars for the privilege.
If an organization uses PowerShell exclusively for various devops tasks and needs a mature, time-tested IDE, you can't go wrong looking at Sapien’s PowerShell Studio.
Source control
In agile environments, code is frequently changed and must be delivered to customers fast. These changes must be captured in a central repository or source control to review changes and roll back code if problems arise. As your organization moves deeper into devops toward infrastructure as code, source control will be vital.
Microsoft Team Foundation Server (TFS). TFS is Microsoft’s solution to devops. One of its core features is source control. TFS’s source control integrates closely with Visual Studio. Although technically not required, working with TFS is best done through Visual Studio. In addition to its proprietary source control repositories, TFS now also supports Git repositories, allowing teams using Git to collaborate on code changes as well.
Microsoft also provides TFS in the cloud. Known as Visual Studio Team Services (VSTS), this cloud-based solution seems to be Microsoft’s primary focus now. VSTS features are incorporated first, then brought to the on-premises alternative soon after. VSTS is free for up to five users, but a fee is incurred for more than five users.
Due to tight integrations with other Microsoft products and technologies, organizations with a core focus on managing Windows services in their devops initiative may choose to use TFS not only for source control but also for its work-item tracking ability and its build-and-release management features.
Git/GitHub. Git is one of the most popular source control repositories available today. Originally developed as standalone repositories, GitHub is a hugely popular service that extends Git to allow you to collaborate with others in a distributed environment.
Git and GitHub both have clients for Windows and work well with the services. You can even find PowerShell support for Git using the open source Posh-Git project.
Git is free to download and use. GitHub is free for public repositories but has many paid alternatives for users that require private repositories or for enterprises.
Build and release
The premise of devops is to deliver quality software services to users at a faster pace. To do this, organizations must have a standardized, predictable, and rapid method defined to deliver developed code to the user. This is done through a release pipeline.
Microsoft Team Foundation Server (TFS). In a Windows environment, you might expect that a Microsoft product would be at the forefront of an organization’s release pipeline and you’d be right. TFS is at the core of the Windows devops space. Its build management process and release management features make it an excellent choice for organizations that have a large Microsoft presence.
For a great concept of using TFS in a release pipeline, check out a whitepaper entitled “The Release Pipeline Model” by Michael Greene and Steven Murawski.
Jenkins. Jenkins is another product that’s popular among devops practitioners. This open source project delivers software from developer to user through a build process. It has a plugin architecture and is known for its wide array of plugins capable of hooking into nearly anything imaginable. Although not Windows-specific, Jenkins can be installed on Windows as a service because it is built in Java.
If using Jenkins with Windows, be sure to install the PowerShell plugin; you will likely work with Jenkins to deliver PowerShell scripts.
Team City. Team City, like Jenkins, is built in Java and, again, not Microsoft-focused. However, unlike Jenkins, Team City is not a free product, though it has a free license. Both Jenkins and Team City should be explicitly set up to run as a Windows service. Since both are Java-based, getting a build server up and running is not quite as straightforward as it is with TFS.
Configuration management
If an environment can’t be configured correctly, the code that’s delivered won’t be able to perform. Configuration management tools assist in your automation efforts and are critical for success in a devops organization. Other than Desired State Configuration (DSC), most Windows organizations will find that the core focus of configuration management tools are not Windows-based. Although all support Windows in some way, it’s clear that the major focus of these tools is on the Linux community.
Desired State Configuration (DSC). Microsoft’s vision for devops, DSC is a configuration management platform that can manage a wide variety of facets of an environment. DSC’s syntax is like PowerShell’s, and it can execute PowerShell code seamlessly. However, DSC goes beyond PowerShell, as it was designed to manage configuration items declaratively.
DSC is part of Windows and is commonly used by other configuration management tools. Although DSC can be thought of as a competitor to other configuration management tools, Microsoft has publicly expressed that it is not. Instead, DSC is meant to act as a platform on top of Windows that other tools can leverage.
DSC will be a core component in any Windows devops organization either as a standalone tool or as a platform for other configuration management tools.
Chef. Chef is an automation product that performs many different tasks from configuration management, compliance, and a build-and-release process. Although the Chef Server must be installed on Linux, Chef has support for Windows nodes through various Chef cookbooks and Chef resources.
Chef is capable of executing arbitrary PowerShell scripts on nodes, delivering DSC script configurations, or invoking DSC resources directly through dsc_resource. On Windows nodes, administrators will spend most of their time writing DSC resources for the Chef client to invoke.
Puppet. Puppet is another configuration management product like Chef. Puppet consists of a master server that runs Linux as well, but like Chef, it supports Windows nodes. Although late to the DSC game, Puppet has recently started supporting DSC. This is good news for Windows shops, but Chef remains ahead of Puppet on Windows.
Puppet has Windows-specific modules that manage many common Windows tasks. As with Chef, however, administrators will most likely spend a lot of time building DSC resources or PowerShell scripts for Puppet to execute.
Ansible. Ansible is a product that behaves a little differently than Chef and Puppet. Ansible is known for its agentless architecture ease of use, but unfortunately not it’s Windows support. Like the other tools, Ansible provides support for Windows in the form of modules to a limited extent. Currently, there are no company-provided DSC modules; only community modules exist.
Like the others, Ansible also requires a Linux server to run on but does not need an agent. Ansible will communicate to Windows nodes over PowerShell remoting (WinRM) to execute commands remotely.
Test frameworks
Another fundamental piece of a successful devops organization is automated code testing. Building unit, integration, and acceptance tests throughout the software development lifecycle is crucial to delivering reliable code. In a Windows devops team, the code of choice is probably going to be C#, PowerShell, or a combination of the two.
Pester. When writing tests for PowerShell code, Pester can help. Pester is a unit testing framework written in PowerShell that allows administrators to write not only unit tests but also infrastructure tests to verify various environmental configuration items. Pester is only capable of testing PowerShell code and is not capable of testing other languages.
Pester is currently the only testing framework for PowerShell, so options are limited in this regard, but it has proven a reliable testing framework. Although an open source product, Pester comes built into Windows, so it's a convenient testing framework for PowerShell code.
nUnit. If testing C# code, a popular choice of testing frameworks is nUnit, an open source unit testing framework for .Net. Most modern build-and-release tools have direct support for nUnit through build tasks. Because nUnit itself is written in C#, it makes an excellent testing framework to use for Windows devops organizations.
nUnit is a community project and free to use. In fact, Pester is capable of outputting nUnit-specific XML, so tools like TFS, Jenkins, Team City, and the like can display Pester test results natively.
Summary
Devops in the Windows world is still in its infancy, though growing like wildfire. The community and tool ecosystem still have a lot of catching up to do when compared with Linux support, but it’s great to see devops tools not directly released by Microsoft beginning to support Windows. And it seems the devops world is now focusing on ramping up Windows support across the board.
As you’ve seen, there are a lot of choices in tools to use in an organization’s devops journey. At the end of the day, each tool must touch the operating system in one way or another, and the best strategy to do that is through PowerShell and DSC. As a Windows admin, focus on learning these technologies first. Once you do, you’ll find adoption of any of the tools mentioned here to be significantly easier.
Related articles
- Deep Dive: The essential guide to PowerShell for Windows, Windows Server, and Exchange
- Review: Ansible shows the beef
- Review: Chef 12 fires up devops
- Career makeover: From ops to devops
- 9 hidden talents of a devops ninja
- 7 signs you’re doing devops wrong
- Essential Azure automation tricks for Windows admins