Monday, September 18, 2017
TL;DR: Take copious notes when you change something in VSTS, every time the opportunity presents itself.
Clearly, there are far more than 10 Practical Tips for Azure and Visual Studio Team Services - especially with a platform constantly improving itself - in fact, I thought of another one while troubleshooting the Figaro build/deployment process today.
If you're not familiar with it, Figaro, in its current implementation, is a C++/CLI integration layer to Oracle Berkeley DB XML, an embedded, native XML database that runs in your application process. This platform consists of an XQuery language engine (XQilla), an XML parser (Xerces), and of course the Berkeley DB XML database engine that drives everything. I put together the initial build/release process for this product in VSTS back in early 2016; previously it all had been done manually, and while I don't like thinking back to those days personally, the process has been moderately complex, and a good topic for another post.
It gets very easy to dive into your build or release processes and start making incremental tweaks here and there in the hopes of resolving whatever issue you're currently facing; over time, however, you may find yourself looking a bit dumbfounded at your builds and releases, wondering how things are working at all.
Here's a picture of mine. As you can see, I could do a better job detailing my changes. I've made a number of edits over the last few days trying to troubleshoot a Figaro NuGet deployment issue. Now that I've managed to fix it, I probably won't be back in here for a while. And that begs the question: will I know what I was doing three, six, nine months from now if I need to troubelshoot something?
Change management is an important part of DevOps as it is any other IT facet - do yourself a favor, and make copious notes about your changes. You never know when they'll come in handy.