Bot-ing All the Way

DateTime.AfterPost - DateTime.Now = 3 minutes

A few weeks ago we received a new muscle in the area of project management in the form of a new recruitment. After recovering from the shock he was on how we manage, well, everything, we began to work on improving.

One of the things we started with is how we manage feature requests and bugs. Up until now, it wasn’t really managed. Actually, it was pseudo-managed, which is the worst situation. You think you have it managed, but in reality it’s a chaos. 

We didn’t really document anything, requests got lost, bugs were repeating themselves. In short – not an optimal situation.

I haven’t realized this. Being inside, swimming with the flow, it’s hard to see these kinds of things. Even though I consider myself an always-learning type of guy, this went right past me.

We did survive as a company for many years working like this, but an improvement is always welcomed.

We sat one day and tried to figure out what would be the best way to manage requests and bugs. We knew it had to work with Azure DevOps (ADO), as that’s the place we manage our backlog. But, if we just told everyone to open us “tickets” in ADO, it wouldn’t really work.. 

  1. Not all of our users use ADO and some may find it “too technological” for them.
  2. Even if we taught them how to work with it, they could just write whatever they want, as any type (bug, feature, epic and such) and under any item. We wanted to allow them the minimum required.
  3. And even if we managed to make it work, we know that sometime in the near future we’ll be moving out of ADO to another system. So all the training will go to waste. 


All these constraints had a simple answer, we have to make some kind of abstraction on top of ADO. 

Bot saying hello
Rocket.Chat Logo
Azure DevOps Logo

Then came the idea for a Bot. We use Rocket.Chat for communication and it has a great framework for writing bots. We considered creating a bot that will help the users open us tickets.

I took the job to myself and searched for something already existing (As I mentioned here) but couldn’t find anything. 

So I looked at how to make it by myself, and saw a very simple SDK for this. 

Challenge accepted.

I was happy to work on this. First time I write a bot, although simple, still very effective. 

As I don’t really have time for this on weekdays, I took it on myself on the weekend. It really didn’t take more than a few hours to make it up and running.

The whole code is open sourced here:

ADO ticketing is obviously supported, but if I worked on a bot, I made it worth it. 

It now supports ADO ticketing, ADO wiki search, static commands and has a very flexible structure to add more commands directly to the configuration. 

I think the infrastructure is quite simple for developers to add more handlers. 

It runs from nodejs and I’ve included a Dockerfile

You can ask it for ‘help‘ and it will print all the things it can do. 

If you want to get some help on adding more functionality, just ask it for ‘devhelp‘ and I tried to write as much information as I saw important for a developer. 



No Comments

Add your comment