At Medidata we provide a number of SaaS solutions for organizations conducting clinical trials. We believe that if you’re going to ask your customers to invest in a SaaS solution, you need to be willing to do so yourself. To that end we use many SaaS tools in the line of developing our software: GitHub, HipChat, Jira and so on. Having accounts spread across a number of tools in this way causes an administrative headache for managers like me.

When someone joins the company, they have to be granted access in multiple places. More importantly, when someone leaves the company, we have to ensure their access is revoked. While we love open source, we still have code that needs to be kept confidential.

SaaS tools are generally accessible from anywhere – great! – but that means they’re not like the internal corporate systems of the past that could be made inaccessible in one fell swoop by revoking a person’s corporate network access. This is a new problem and one we have to take seriously.

To keep things in order, we have policies in place that dictate what needs to be done. Being software developers we also have a number of tools that help us police them. Our aspiration is to make all of these open source.

One of theses tools, Cleric, started life as an Innovation Time project I did in 2013. Innovation Time is our spin on Google’s famous 20 Percent Time. Being lazy, I wanted to automate away the manual drudgery of the administrative tasks I did as a manager. Of course by “lazy”, I mean in the old Three Virtues sense. I also wanted an opportunity to experiment writing green-field code in a very strict TDD fashion, so this project let me scratch two itches at once.

Cleric focuses on the administrative tasks we perform in GitHub but also ties in HipChat. It’s a command line tool because that seemed like a good lowest common denominator (and I’ll admit I’m a big CLI fan).

At a basic level, Cleric does simple things like add and remove people to GitHub teams and organizations. For instance, to add GitHub user “andrew” to team 1234 you would use the command:

cleric welcome andrew --team 1234

However, it also allows you to perform policy checks at the same time. So, for Medidata, we require a person’s public GitHub profile to include their company email address.

cleric welcome andrew --email=asmith@mdsol.com --team=1234

By baking this check into the tool, we can reduce the number of policy violations, which in real terms means fewer people having their access automatically revoked by one of the other tools that scans our GitHub organization and team memberships.

Another side of Cleric is that it can log all actions taken into a HipChat room. This helps us monitor administrative activity. Aside from letting you be plain nosey, this is useful for the pool of managers who often field requests from across the company. We can easily see in the HipChat room whether a request has already been fulfilled.

Cleric has acquired a few more tricks since I first started it. For instance, it can create a repo, assign it to a team and hook up notifications into a HipChat room all with a single command.

cleric repo create mdsol/new_repo --team=1234 --chatroom=4567

Another interesting item is the ability to check that all changes in a repo are covered by pull requests (again to help in the policing of a company policy).

cleric repo audit mdsol/suspect_repo

Cleric is undeniably rough around the edges. It’s been built out as our demand required but there’s a lot more it could do. It could support other source code hosting options. It could support other chat systems or log actions entirely differently. It could extend the “add” and “remove” people commands to include systems beyond just GitHub; I’ve not got around to adding integrated HipChat account creation quite yet.

We’re hoping Cleric can be a useful base on which further administrative tools of this kind can be built. I designed its internals with extension and alternative back ends in mind. Right now it’s a CLI but perhaps its real future lies in being a library; our DevTools team has already moved our state-of-the-art on by integrating GitHub access grants into a self-service portal for our new employees to use themselves. Perhaps ChatOps is the future… who knows?

If any of this sounds interesting, help us lazy managers, we’d welcome your contributions!