The company I work for (Health Catalyst)*, and the group I work in particularly, is moving towards continuous delivery/deployment (which for us right now means deployable after every sprint, which hasn’t been the case over the past year or so in our development efforts). We use Visual Studio Team Services (VSTS) for much of our tooling, including their new build system. As a part of the build we want to label our artifacts and, though it seems silly, naming/labeling our artifact proves to be a little cumbersome because we like to include the sprint number we are on in the build name. That means this has to change for each build definition that we have (we have quite a few products at this point) and it just seemed silly that we have to either hard code that and change that for each sprint or add a variable called Current Sprint to each build definition and change that every 3 weeks for each build definition.
Changing a build number is trivial (but tedious for the number of build definitions we have) and, since it is a manual process, it is ripe for error, like we experienced recently when we were stamping builds with the number of the previous sprint. The challenge with this, is that this number is determined when the build is queued, so it isn’t something that we can change in a step of the build process while the build is running. VSTS has a great api that provides access to what the current sprint number is and an API to update a build definition (including presumably the variables that are set/specified in the build definition).
Enter Azure Functions which, like AWS Lambdas, allows code to be executed in the cloud. In the case of Azure Functions, C# and Node.Js code can be executed based on a schedule or some type of triggering-events and you only pay for the code execution and accompanying required CPU time. So the idea is, that we write the code to get the current sprint and update our build definitions and then specify the schedule so that is aligns with our 3-week sprint cycle. I’m sure there are other solutions (and I should ask the VSTS folks what suggestions they have for this particular issue – we can’t be the only ones right?) but this just seems like a fun opportunity to automate a tedious manual process we do repeatedly and to try out a new cool technology (Azure Functions code execution on demand).
Pretty simple continuation to my blogging habit, but I’m determined to make this a regular habit and challenge my thinking and growth by sharing and learning from others, even if it means I come off as a little foolish or simple at times. I am excited for tomorrow’s post though. I’m going to introduce some great material I became aware of any in a webinar I recently attended by Dan Ashby (and put on by the Software Testing Club) that will serve as something of a series over the next little while. I’m looking forward to it!
*Note that any posts on this blog are my responsibility alone and do not necessarily reflect the views or opinions of my employer.