I love automation. Automation allows me to manage a large number of applications, services, and infrastructure. Without automation, the only alternatives for me are putting in a lot of extra time manually checking everything myself or hiring bodies to do that for me. The main problems with any alternative is communication and the centralization of undocumented knowledge. I don't want to go too deep down that rabbit hole in this post, but let's say that scenario is bad.
What do I mean by automation? Automation, to me, is about the domino effect. I press a button here that triggers a process, another process, and so on. Each link in the chain is responsible for specific tasks and the communication of whether that task succeeded or failed. A great example in my day-to-day is a simple code commit. I write a detailed summary of what I've changed and send that change to a centralized repository which starts the first trigger. From there, my team is notified of what I changed, the build server is notified for compilation and testing, and the output is automatically deployed. Also known as continuous integration and continuous delivery, potent stuff! And with great power comes...I forget the rest, but the point is that communication and accountability are still the keys to any good process, automated or not. What's the point of a code commit triggering a build and deployment if no one knows? Well, what a great rhetorical question I just asked myself that I will answer anyway! There isn't.
I, like many, didn't build all of this automation myself. I use a series of great tools to get it done for me. That's not to say that significant time hasn't been spent configuring and filling the gaps, but for the most part, finding the right set of tools is everything. The primary tool in my belt that inspired me to write this post is HipChat. Like others of its breed, it's primarily an online persistent chat service like IRC of old but for the modern web. HipChat is invaluable to my team and me because of its incredible accessibility and extensibility. It's got an app on every major platform, a fantastic open web app, and a simple yet powerful API to integrate with. So all that communication stuff, I think, is so important; this is where it all happens for me. I love HipChat so much that not only does all chat take place there, but it's also what all of my wonderful tools talk to. Each link in my automation chain, at some point, sends information to HipChat so the appropriate people can be informed. Code commits, builds, tests, server alerts, and anything that works by itself and has something to say to humans goes to this central communication hub.
It's not all roses, but where there is an API, there is a way. Luckily most of the tools I use have built-in support for communicating with HipChat, which is fantastic. However, for services like TFS, there is no one-click solution. But like all excellent services, they typically have great APIs, and TFS is no exception. So since TFS is such an essential tool in my day-to-day and HipChat is the cornerstone of all communication, I had to get these two services talking. After some investigation, I determined that the easiest and most effective way was to poll the TFS OData API for the changes I was looking for and then pass that along to the appropriate HipChat room. There was at least one push-like alternative that TFS offers, but for my needs, it was far too complicated and didn't offer the information I wanted to communicate. So I started a simple project a few months ago called TFSChanges that does essentially what I'm talking about. It queries the OData API for specific projects looking for recent changeset and build information. If found, it formats and pushes that information out to any configured provider...which in this case is only HipChat, though I'm currently adapting it to do more over time as needs and features change. But since this has helped my team and me so much, I decided to spend time adapting the code for open source and released it yesterday. I've written hundreds of little utilities like this over the years, but this is my first attempt at making something that can still serve my proprietary needs and live on the open web for others to fork and use. Nothing should be hardcoded, and all private information and settings must be scrubbed. Which sounds easy, but I assure you it's not. But without going into all the gritty details of scrubbing git history and removing config settings, it's done now, and I plan to release more mini-projects like this moving forward. I figure that even if one person finds it useful, then it's probably worth doing. I know I've counted on and used countless niche open-source projects in the past if only to look at the code for ideas and use it entirely differently. If it helps you automate, then all the better. You can check out the repo here https://github.com/sirkirby/TFSChanges, which describes how to get it up and running.