Bots at community service

Local software community/meet-up management involves a lot of repetitive tasks: event publishing, notifications, statistical reports. Groovy, AWS Lambda, Terraform and Slack appeared to be a good combination to help creating valuable automation scripts and bots integrated into team’s chat and ready to help.

It’s about the community I’m part of for last 3 years - LatCraft. It is the community of awesome Latvian software craftsmen and craftswomen. We host events, where we invite amazing speakers from across the world.

The challenge

Announcing an event takes a lot of effort. We use Trello board to remember all the things we have to do:

There are so many systems, where we need to publish data about the upcoming event to make it efficient and cover as much audience as we can:

Simply copying and pasting the same information over different services is not error-prone. It’s also extremely annoying to do it over and over again. Typos, broken links, updates, … argh!

Publishing

We started by writing some helper scripts in Groovy to smooth the process of event publishing. Over time we realized that event data should be read from only one source to avoid copy-pasting errors.

So, the role of master data is played by the JSON file, from which we generate our website. All our scripts (and later on, our bot commands) read (and eventually, also, write) data into that file.

Initially, we were happy with our Groovy scripts. But since we wanted to spread publishing responsibilities among our team members and not all people were comfortable enough to run those Groovy scripts (not all folks are active Java developers and some are even non-technical at all), we had to find a more convenient way to help with publishing process.

That led us to the idea of creating a set of integrations with Slack, where most of our discussions happen.

Let me introduce you to the CraftBot:

Each of the commands was originally a Groovy script, which is now deployed as a separate AWS Lambda function, but will get into technical details later.

The first thing, which is done by the person responsible for the event publishing, is to create a new event record in the master data on GitHub. Then he or she has to execute a series of CraftBot commands to publish event information validating and fixing any typos on the way.

We usually start with posting event information to EventBrite. This can be achieved now with a simple command:

CraftBot reads event data from GitHub, creates a new event in EventBrite and updates master JSON data in GitHub with a link to ticket registration. That data is immediately picked up by website building CI process (handled by TravisCI), and, in a minute or so, website is ready to accept registrations.

If there are any typos or updates, the event publisher can fix them in the master data and then reissue CraftBot’s command to update the desired service.

We also generate a set of event cards to share them on various social networks. For example, this one:

Or this one:

We share those cards on Facebook:

Twitter:

Linkedin:

The final step is to generate invitation e-mail for loyal members of our community:

Sendgrid is used to send our invitations. Responsibility of the event publisher is to validate the layout and text of the e-mail:

Ready! Steady! Go!

Sent! Now the community knows about the event:

We can sit, relax and observe the incoming registrations. Of course, there is a CraftBot command for that:

Implementation details

All CraftBot sub-commands are sent through the main /craftbot command implemented with the help of Slack’s Slash command integration.

Slack sends command information to a service running on AWS behind API gateway.

Then it is picked up by our main AWS Lambda function (router), which knows how to map Slack command data to invocations of our Groovy scripts that are deployed as a set of other AWS Lambda functions. High level stack looks like this:

The actual routing code is very simple as well:

I can describe many more technical details, but a picture is worth a thousand words. The following tools/services control provisioning of the infrastructure and continuous integration/deployment of the code:

This picture describes all the integrations between CraftBot and external services:

The following repositories are involved in the event publishing processes:

Looks cool, ah? How much does it cost? Zero, nada, nothing! That’s the invoice I get for our AWS Lambda functions:

Conclusion

What we achieved with all that automation:

• Decreased error rates
• Event publishing log is in Slack (everybody can see that and repeat commands)
• Non-technical team members involved in publishing
• We don’t pay a penny!
• Happier team!

For curious ones, the code is available here.