At what stage should coverity static analysis be done?

user_13166004 0
Viewed 257

When should we do coverity static analysis (no build, buildless capture since we don't use compiled language) in our CI lifecycle? We have stages like test, build, deploy. What are the pros and cons of different approaches?

This is for a django application which is deployed onto kubernetes. test stage involves testing django end-points. build stage involves building a docker container. deploy stage involves rolling out the recently built docker image.

If I were to create a new stage when should it be done? Any convention followed while doing this?

coverity continuous-deployment continuous-integration django
1 Answers

Deciding where to put certain checks in your build pipeline is a matter of what you want to get out of those checks.

A build pipeline should give you fast feedback first and foremost. You want to know as quickly as possible if there's anything significant that should stop your build from going out to production. That's why you tend to move checks that run fast to the earlier stages of your pipeline. This way you quickly check whether it's worth it to move on to the slower, more cumbersome steps of your pipeline.

If your static code analysis detects issues, do you want to fail the build? If so, this might be an indicator to put this step early into your pipeline.

How long does your static code analysis take to analyse your codebase? If it's a matter of a few seconds, you can put it into an early stage into your pipeline without thinking too much about it. If it takes significant time to build (maybe tens of seconds or even minutes) this is an indicator that you should move this to a later stage so that other, faster checks can run first.

You can but don't have to put static code analysis into one of your existing (test, build and deploy) stages but there's no one stopping you from creating a dedicated stage in your pipeline for that (verification maybe?).

There's no reason to be dogmatic about this. It's valuable to experiment and see what works for you. Putting emphasis on fast feedback is a good rule of thumb to come up with a build pipeline that doesn't require you to watch the build for 20 minutes only to see that you made an indentation error on line 24.

user_137555030
Related