When working on client projects at Trilix, we have four different deployment environments that help us bring new software to life. These environments allow us to thoroughly vet our software before it makes its way to the end user. While we spend all day creating software to transform our clients’ businesses, it occurred to me that we had our own inefficiency internally managing these different environments.

As a team, we collaborate on development progress through Slack, an industry standard team collaboration tool. We have also started evaluating Microsoft Teams as Microsoft has indicated that it will soon replace Skype for Business and has the Slack features that we need (though not as refined in some cases). With both tools, we post frequent updates so that the whole project team can stay informed on progress that is being made. More importantly, we have configured BitBucket (our source code repository) to automatically post messages to these tools whenever code changes are pushed to our different branches. This allows everyone to easily follow the state of the different environments throughout the day. Unfortunately, we were lacking information on one aspect: Environment Builds.

Our software development lifecycle brings all software changes through four different environments in Microsoft Azure. Every new feature and bug fix starts in development where it is created. Once complete, the changes are pushed to quality assurance (QA) where they are tested. When fully tested, the changes are pushed to staging where the client can evaluate them in a sandboxed environment. Finally, when approved by the client, the changes are moved to production where they are considered live and ready for day-to-day use in the business.

The first three stages are all tied directly to a code branch within BitBucket. Through continuous integration, the associated environments are automatically rebuilt whenever a new change is pushed to the respective branch. When, for example, a new feature is pushed to the QA branch, Azure is configured to automatically rebuild and restart the QA environment in Azure. This is where our inefficiency lived.

When a change is pushed, we see a message within Slack/Teams and then Azure queues a rebuild of the updated environment. At that point, we know that a build will begin, but we have no idea if it was started, completed or failed. Our QA team would rely on the developers logging into Azure to give them the current status, or they would just cross their fingers and hope that the build had completed successfully. Where Slack/Teams had removed our need to manually do many things, we still had this one manual bottleneck. We either had developers stopping to check things for the QA team, or the QA team just refreshing their browser over and over waiting for the change to present itself. Though a few minutes or the occasional interruption may not seem like much, it becomes a huge inefficiency across multiple teams working on multiple projects when happening multiple times a day. It was worth fixing.

In solving this problem, I first verified that there were no existing integrations between these services. Finding nothing, I created a custom web service that sits between Azure and Slack/Teams that uses the webhooks to receive deployment completion messages from Azure’s build process and relay that to Slack/Teams channels. Though Teams and Slack both support webhooks, they care about very different things. My service essentially acts as a translator taking the Azure status data and converting it to the formats needed by Slack/Teams to display a message. The end result is that the team can now see a push posted from BitBucket and know that it will be followed by an Azure Build Status message when the build is complete along with any success or failure information.

At the end of the day, this minor change has had a direct impact on our projects by cutting down on interruptions and wasted time. This correlates to more time to better address the real client issues that we are trying to solve. The amount of time that it took to integrate between these three systems was far less than the amount of time that we would have wasted in the long run. We will be using this integration for all client work moving forward and could bring similar integrations to our clients to help them drive efficiency in their own workflows.


Wondering how to make your business systems integrate more seamlessly with one another? Click here to schedule your complimentary Business Systems Consult to gain greater clarity on how systems integration can support your business needs.

Share this: