Now I call them robots or short bots. You might call them scripts, services, helper tools or simply automation of tasks. If we see that we repeatedly doing the same task over and over again it is time to automate our software development. Let’s see how far we can go and where bots are used by super productive development teams.
Now automation is nothing new in software development. Refactoring possibilities in our IDE’s, build server that runs on every check-in, automatically deployment of new software are things that we got used to in our industry. We don’t think about those anymore. I mean who changes a name of method and all its references by hand or runs all integration and performance tests on their developer machines?
So let’s look at 7 bots that can help you write better code and make you more productive.
1. Flaky Test Detector
Who doesn’t know the frustration when a build fails, you spend some time looking at the logs and the code but you can not find an obvious reason why a specific test failed, re-run the build and it succeeds. Yes, you’re a victim of a flaky test.
Our Flaky Test Detector re-runs a failing tests automatically. If the second run of the test succeeds we’ve found a flaky test. The detector automatically continuous the build and put the test in quarantaine. That means it won’t be executed in a following build. At the same time the Flaky Test Detector creates an issue for fixing or deleting the test.
Last year the Confluence team has found 817 flaky tests and put them in quarantine. 817 times on not investigating and re-running the build! That are a lot of developer hours.
2. Production Problem Reporter
What happens at your organization when a service fails in production? Maybe employees in operation start noticing it and may restart the service. If that doesn’t solve the problem they probably going to inform the development about it. But who to inform? And why isn’t the development informed directly?
Pagerduty is a great tool that people use to inform developers and operation employees on problems. We use it also at Atlassian, but wanted to avoid setting up responsibilities per service. People will forget this especially when deploying a brand new service.
So we’re using the deployment descriptor of the service to teach Pagerduty which developer team to inform on problems. It’s a small but very powerful bot that helps our dev team to own their code end-to-end and saves our ops team time to figure out who to call.
3. Release Notes Writer
Pulling together information for release notes can be painful: What did actually went into the master branch? Is the information in our issue tracker up-to-date? A good practice is to contain the issue key in the closing commit message, so you can go through the commit history and be sure that you catch every feature, bug or improvement for the release.
But if you release hourly, daily or even weekly this could be very annoying. E.g. ZeroTurnaround & Hazelcast using bots to find the commits, grab the information out of the issue tracker, generate release notes automatically and make them public.
Hazelcast is using GitHub with Github Issues and ZeroTurnaround Bitbucket with JIRA Software. This way you also spend more time on writing issue descriptions, making them more problem centric and focus more on the customer value that a specific issue creates.
4. Log File Problem Finder
We’ve developed a bot called Hercules that can analyze log files. If customer have problems with their local instance they submit a ticket on support.atlassian.com and get an option to upload their log file. Hercules examines this file and point out potential problems via a comment.
Behind the scenes our support engineers have build a knowledge base in Confluence with a machine readable part on each page. It’s basically kind of a regular expression that Hercules uses for analyzing the log. The rest of the page describes the solution of the problem, so the support can immediately reach out to the customer and suggest steps to fix the issue.
For developer that means less log file analyzing and interruptions. We’re still trying to improve Hercules for internal use before we will eventually open it for customers to do self-service with their instance. And we’re so proud of this service that we created a special t-shirt with a follow up comment from a Hercules suggestion.
5. Stand up Reminder
Stand ups happen regularly each day at the same time so you can assume that all team members are aware that a daily meeting is about to happen. But sometimes they chat with other colleagues or they forget the time.
At Atlassian every team has at least on TV that they use as an information radiator. Current development information is shown in a browser tab. We use that so called Wallboard to remind people about the upcoming standup. An engineer developed a Chrome add-on called Crontabs that opens a tab at a specific time with a specific URL. We use it to play music from a streaming service.
So if you hear ACDC playing you know, it’s time for your daily standup and you have one minute to join your programming buddies. If it’s Taylor Swift, you
know it’s the marketing team’s stand up ;).
6. Engineering Health Checker
If you’re long enough into programming you know that code gets messy over time: Long classes, use of deprecated methods or increasing compiler warnings. Yes, we should constantly look out to fix those but somehow we’re lazy and it feels better to write a new clean shiny class instead of improving an old one.
We didn’t wanted a static code analyze that breaks the build – The software is fully functional even though a team member just wrote a new JUnit 3 test instead of using JUnit 4. So we wrote a bot that does can analyze the code and recognizes these engineering health issues.
Instead of a build failure we wanted to rise the social pressure on people. We build a ‘Hall of Shame’ for our Wallboard that shows the face of an engineer that just introduced a new health issue. Those who are working to improve the existing code base enter the ‘Hall of Fame’. It started with a single check and now we’re checking over 50 different health categories.
7. Automatic Merging
Git is very good in merging code lines. Most of the time merges just work. So why not use that power to automatically merge the code?
At Atlassian we develop software for the cloud as well as for installing on your own server. There are several versions of our software out in the wild at our customers. When we find a bug in an older version (let’s say 3 versions back) we need to fix it for all 3 versions as well as for our current development.
We keep our released version each on a separate release branch. Now we apply the fix for the oldest version let’s say 2.0. A git hook kicks in and merges the changes all the way back to following version 2.1, then to the following version 2.2 and so on until it hits the development branch. An automatic builds starts for each of those branches, all tests are executed and on success we release the artifact automatically to our webpage. Here is an article with more details.
More bots, more details?
I did a presentation about bots at JavaOne 2015. You can watch the video and download the slides.
Sven Peters 