Using DeepCode.AI in your CI/CD pipeline

I started using DeepCode.AI a few months ago, initially just sporadically for GitHub projects to get a feeling of the product and eventually leveraging their Visual Studio Code extension for real-time feedback in my IDE.

Now, I just went one step further: Integrating their code analysis into our CI/CD pipeline. DeepCode offers a CLI with a fairly simple command:

So basically all you need to do is adding that command, for example in your CI/CD pipeline.

Configuring GitLab Runners

Since we use custom Gitlab Runners on for our build pipeline, I decided for a custom stage in my .gitlab-ci.yml, making it easy to convert this into a GitLab CI template or simply making it a bit more re-usable.

First, ensure you have a build image with python 3.6+ installed. Install the deepcode python package. Get the DeepCode API Key from their UI, and plug that into your pipeline, for example via GitLab environment variables.

Adding AWS KMS

In case you run your GitLab runner on AWS, you could use AWS KMS to encrypt credentials such as the DeepCode API Key:

The .gitlab-ci.yml file can now be enhanced with the decryption step of the encrypted DeepCode API Key. This eliminates the need of using environment variables or other customization in your GitLab project.

This is the .gitlab-ci.yml build step I ended up using:

Doing this was already worth the effort. In one of our projects it found a potential UnhandledPromiseException from a promise chain, which was easy to fix. But such bugs will now be stopped before code gets merged.

Operations Teams vs. Engineering Teams

Or: How to use incentives to stop constant escalations

There are many differences between a team focused on operations and a team with an engineering approach. I could go on for hours (or likely, for days) with a rant. But let’s narrow it down to a few key aspects.

Effective vs. Efficient

Operations teams are highly efficient. They get a support ticket, they jump on it, they fix it, the declare success. They have KPIs on how quickly they solve tickets, how many tickets they solve. They have leader boards on identifying the hero of the week. Management supports this further by promoting the fastest. This is an incentive to beat these metrics. Operation teams actually script and automate every overhead to become more efficient. In short, they automate all the waste that shouldn’t even exist in the first place. This is true in all types of organizations, for example an operations-led data team or a customer support team.

Engineering teams on the other hand hate support tickets. They address the root cause. Was it a bug? Let’s fix it. Was it unclear documentation? Let’s clarify it. Was it a hard-to-use user interface? Let’s simplify it. They think in eliminating waste instead of automating it. They are not efficient, but highly effective in what they are doing.

Low vs. high noise level

Operations teams love escalations. Love when something is on fire. This is excitement. There’s something to jump into and start solving. Once it’s solved, this is often recognized in Emails reaching a large audience on the heroic efforts. And the worst? A week later they have another escalation for the very same reason!

Engineering teams are led by people who avoid escalations at all costs. And if they happen, they look into the root cause, address the root cause to solve them for the long-term. They will still thank their team for heroic efforts on a weekend, but they’ll recognize twice as much the work that was done to prevent the same thing to happen again.

Better vs. more

is a bit of a continuation of my rant. But it’s still a key aspect of a team’s culture. Engineering teams want to have better tools, better-skilled team members, better tests. Operation teams want more. They want more people on their team to handle even more tickets. More escalations to have more processes. In many companies, more often means more budget and more power on the decision table. One team puts the solution at the center, another one the team itself. It’s a very human reaction to want more, and for leaders who are human to incentivize more. Giving recognition for less is hard. But today is a good day for you to start doing this.

What’s next?

To round it up a bit, terms like “DevSecOps” got invented to build development, security, and operations into the team’s responsibility. But it’s actually much more. Product ownership, requirements engineering, project management. We actually need a new name that captures the broad aspects fo a team’s work, but I leave this for another day.