Cue drum roll….
Why yes, yes we do.
Like most other companies, we try to find ways to improve what we’re doing in order to make life easier and be more productive. One of the key ways we do this is by using ActiveBatch for our internal automation needs. We have processes that allow us to get things done in a deterministic way, with almost every department from HR to Engineering taking advantage of our own software to run them.
In this post, we’re going to talk about one of the primary ways we use ActiveBatch in our Engineering department- for DevOps processes.
Agile methodologies (SCRUM, Lean, Kanban, GSD, Extreme Programming, etc.) make great use of automation because some of their founding principles are articulated around short, quick development cycles. In addition to this, they also explicitly separate team management and product development. In doing so, the goal is to have developers do what they do best: develop. The rest is easy to automate.
Here at Advanced Systems Concepts, our Engineering department employs the SCRUM methodology for our software release cycle. User stories are created in Team Foundation Server (TFS), prioritized, implemented, and closed.
So let’s take a look at how we use the very product we develop, ActiveBatch, to automate our own development processes.
Managing User Stories
One of the most significant benefits of automation is the quick feedback loop it enables. As we continuously test our software, we use the Create Work Item Job Step that comes with our TFS integration to automatically create new stories when tests fail. ActiveBatch updates user stories and automatically assigns testing tasks to QA that go back into our agile processes. These stories are triaged by our Scrum Master and prioritized by our Product Owner. As a result, developers know right away if they break something, without having to start the application.
ActiveBatch's Team Foundation Extension
Generating Artifacts and Reports
One of the requirements of SCRUM is that the Scrum Master generates reports and statistics on how the team is doing. This data then feeds into the evolutionary nature of SCRUM. Most agile implementers use Excel or TFS’s built-in tool to generate reports. While these can offer some basic functionality, they often take a lot more time and effort on the part of the SCRUM Master. Instead, we use ActiveBatch to generate these reports.
Using the Get Work Item and the For Each Work Item Job Steps, we are able to generate a visual table based on custom TFS queries. For example, this can be the list of stories planned for the new sprint or the list of closed stories for the sprint we just reviewed. We use our Email Job Step to send out this information via email to the team and other distribution groups. By automating this facet of agile, the SCRUM Master can free up some time to be more creative and focus on improvements to the agile process, rather than having to generate artifacts or taking time to manually run and email reports in Excel or TFS.
Automated SCRUM artifacts email
Ensuring Clean User Stories
Typically, we close about 1500 development tasks a month. Therefore, it’s essential for us to keep everything in order. Statuses must be accurate, key fields must be filled…you get the picture. In order to facilitate this, we built a series of TFS queries that we run through our Get Work Item, which produces an email that points to the issues within our tickets. This has been very helpful in making sure that our product backlog (our list of stories) is always clean and usable.
TFS Health Check Email
Automating the Build Process
ActiveBatch kicks off the new software build for every check in. As soon as the build is completed, ActiveBatch automatically deploys that build installation every few hours as needed by QA. Then, via a command line program, it installs the kits into the production environment. Following this, ActiveBatch will verify the installation files are correct and an email will be sent out alerting the proper users that production is ready. We found automating deployment with ActiveBatch minimizes significant lag time and removes delays that would otherwise occur with manual deployment.
Economists often the use term, opportunity cost, to define the loss of value from other choices when one choice is taken. Especially at the business level, organizations often ignore the opportunity cost of having to build homegrown solutions or use in-house resources for manual tasks.
For virtually any project, there are certain aspects that can be automated and those that can’t or may simply not be suited for automation yet. However, by having an automation-first mindset, you can free up developers and testers to be more creative and tackle higher level projects, instead of spending increasing amounts of time on routine, mechanical tasks.
Learn more by downloading our free White Paper, Overcoming the 4 Critical Challenges of IT Operations: