We are developers, and as developers, we often need to do some Continuous Integrations. I would, rather, even say that we need to do various automation because CI is not the only thing that we do when we need to automate things.
The automation/continuous integration setup itself is not boring – it’s always side work, which needs to be done, but not as often as the general work we do. But the results that most CI systems are producing are usually unexciting.
The same text, the same few lines of texts, the same number of test runs, the same number of failed tests, maybe there are some other metrics on your project…
1. Name your Integrator User.
You probably know a few famous systems names like : “Siri”, “Alexa”, “Cortana”, “M” etc. Can you imagine everyone calling them “Speech Interpretation and Recognition Interface” or “Intelligent Personal Assistant”?
2. Change default commit status messages on the Github.
By default, in case of Jenkins, you’ll have “default”, or in the best case, you’ll have some-continuous-integration-system-name. Boooring. We need more fun!
Let’s update our Jenkins configuration a little.
|Commit Status Context||⛵Buildboat|
|Commit Status Build Triggered||☸ is setting sail|
|Commit Status Build Started||☸♪ is looking for adventures ♫⛅|
|Success Message||☀⚓⛱ has successfully arrived|
|Error Message||⛈⛰☠ has crashed by cruel reality ¯\_(ツ)_/¯|
|Failure Message||⛈⛰☠ has failed to reach destination ¯\_(ツ)_/¯|
See? This looks way more interesting than default “Building… Build Started… Pending….” texts. Be creative!
3. Add some phrases that only you know for triggering the build on PR.
“Abracadabra”, “Run, Forrest, Run!”, “For the Horde!” be creative 🙂 But always leave a default one like “Rebuild, please”, which will be understandable by the people who aren’t bored enough.
4. Visualize your metrics
Instead of showing rough numbers or the percentage of something, you can use (hate to say it, but emojis:) Most of the messengers will support them. Slack, for example, supports custom emojis—so, in this case, your fantasy is the only the border you have.
For this one–here’s a true story about how we were fighting with warnings on our project.
We had a project with a lot of warnings in it. I wouldn’t say that we’d always had projects without warnings up until then, but this one was just crowded with them. So at one of the retrospectives, we decided to remove them. It wasn’t possible to remove all them at once, so we decided to decrease them with every Pull Request.
And that worked for a while.
We dropped the warnings count from 400+ down to 180 in a really short time.
And then after some time everyone just stopped paying attention to the warnings count, just because it was hard to track what the number of warnings were before you started to edit code. Also, there was no visible progress, so the primary goal switched to “at least let’s not introduce new warnings.”
A few months passed in a big rush for the features, and even though we weren’t adding new warnings, we still had about 200 of them at the end.
And then we added a warning counter which was recalculated on every commit in open Pull Requests. It’s a bit strange, but there are not that many tools which can calculate warnings count (https://github.com/jlyonsmith/xcpretty-warning-counter).
After that warning counter values started to decrease dramatically—everyone saw the real state of the problem, and subconsciously everyone was trying to lower its value, which everyone was able to see in the chat. We started to try to fix a few warnings in each PR—at that moment there still were simple warnings like incorrect casts, unused variables, etc.
The warning counter started to work even better as soon as we added different emojis for different warnings count.
Here are some examples of emojis we’ve used (it’s not a full list since we still have about 30 warnings) and each level has a new icon which can be added by anyone so it’s a big surprise to see what you’ll get once you fix few more warnings.
So the point is if you want one of your metrics to be changed, make sure that it’s clearly visible by everyone. Add some gamification if you want to make that part be done quickly.
Here are our emojis for different warnings ranges:
5. Formalize, automate and visualize your process.
Formalize your process.
Do that in whatever way you like, but write down every step you need to perform and check. By doing this you or the person who will make a submission on your behalf won’t miss a required step, like checking for correct dev/prod environment. ¯\_(ツ)_/¯
Once you formalize every step of the application submission, automate every possible part. This will probably take a while at the first, but once you’ve done it, you’ll never look back.
You can write your own scripts for the process, or use one of the available tools, like Fastlane.
For the submission process, I, personally, would recommend using Fastlane—you’ll still need to have some knowledge about the signing and submission process, but this tool could save hours of script writing. Fastlane also has really good documentation, so even a new user will be able to use it.
And finally, once you’re done with automatization, visualize this process.
P.S. Someone could say that this is child’s play. Well, it’s true—we’re playing kid’s games when doing these things. But these really small and really easy-to-implement things often makes a difference between “yet another project” and “don’t know why, but for some reason I’m still on this project and I kinda like it”
Formalize -> Automate -> Visualize -> Have fun and don’t get bored!