ChatOps – a new concept
Until this day, I’ve heard of DevOps, got to know almost everything about it, got a little into its history with a colleague from work, and found out that the concept exists since the ’90s but the term wasn’t quite fixed yet. It was just a concept that not everyone knew exactly what is with it, so basically each person had its own view about this DevOps thingy…
But this post is not about DevOps, I mean it is, kind of… it’s more about ChatOps.
Just today I found a YouTube vid with Jesse Newland that speaks about this concept during his work at GitHub. Clearly, the discussion is focused on Hubot and how it shows Build information or Show notifications in Campfire regarding Deployment, automate graphing, provisioning etc…
After seeing this video, it hit me. I just realized that I’ve worked with this concept of ChatOps 3 days ago at work, while trying to keep everyone connected to Slack by keeping all information about
- Jira issue statuses
- Project management from Slack chat
- Creating our own Slack bot
- Creating our own Slack Integration
to make our jobs easier and clearer, without wasting any time on useless half-an-hour meetings that bore the hell out of everyone.
Everyone was working dispersed, communication itself was dispersed, we used Skype, Hangouts, Slack, Telegram for chatting and conferences.
Massive changes happened on the master branch in our private GitLab repository, and whenever we branched from master to work on features, shit gone loose, because no one used to notify anyone about changes that had major impact on the application.
People were keeping branches for like 2-3 months without updating them with master or merging them in the master branch, because feature branches must die quickly!(I thank a friend of mine for telling me this many, many times) That’s it man, you must kill those son of a b*tches, that’s they’re purpose, to die quickly.
No one knew when New bugs were added on Jira, or nobody knew when the status of the Jira task was changed from Backlog -> In. Dev, and then from In Dev. -> Ready for QA etc…
The best choice that I found for these problems is to stick with Slack. And how was I doing this:
- I figured that meetings must be automated in case some Project Management is needed
— Mincă Daniel Andrei (@daniell_andrei) April 6, 2016
- I then got to the point that, we also need to get notifications on Slack, whenever a user started a deploy on JenkinsCI
- this way the testers, that are also in the Slack group, would get notifications of deployments, and can start testing
- then I figured that we also need to get notifications for Jira task Status Changes, like if it goes from Backlog -> In Dev; In Dev. -> Ready for QA; Ready for QA -> DONE
- this way testers knew that job was finished for a task immediately and followed by the deployment notification, they were sure that the feature was ready for testing!
- then I thought that “would be good if people would start tasks directly from Slack, for example /start task_id” so I started this project to work on a Bot
- other commands included of course, like: finish task, pause task etc…
- another useful command would be to display currently active tasks, and this way you can manage those that you forget to close
Try to work as clean as you can, without leaving any trace behind. Clean your Jira issues, clean your github branches/commits/commit messages etc. The process of keeping everything clean must be done along the way, not separately.
Imagine yourself as a Hitman that never leaves any trace after killing it’s victims (jira issues).
- then it would be good if Developers would get notified whenever a Merge or Push on the master branch was done
- GitLab must be integrated with Slack to fire up Merge, Push, Commit requests…
- Think of which filters must be added, ’cause not all the information is good
All these mentioned above are in a Work In Progress stage, I like automation and information represented clearly. I think that everyone deserves some spare time to smell the flowers, get a sip of his great coffee, smoke a cigarette or anything else…and let those damn machines do our repetitive jobs!
But machines are like too damn stupid to understand human language, and that’s why a glue exists between human race, and the machine, Deus ex Machina:
- programming languages
- Infrastructure both large-scale and small-scale
We are humans first of all, and we’re not error prone. I bet most of you Sysadmins did at least once a great mistake like issue in terminal sudo rm -rf / or anything else (don’t try this…).
THAT’S WHY AUTOMATION IS HERE, use it at its full extent.