5 Barriers that Supercharge Deployment to Production

It may seem counter-intuitive but, setting up the appropriate barriers in your CICD pipeline can speed your code into production. Having a solid set of quality gates setup and automatically enforced can supercharge your team’s performance, make folks happier and more confident all while delivering high-quality code.

supercharge

Lint:

Reading code written in an unfamiliar or inconsistent style is like reading poor handwriting. The code may be correct but it can take a ton of energy and brain cycles to simply understand what is going on. Conversely, reading code that adheres to a familiar style allows you to focus on what is important. Whether it’s someone else’s code or your own that you are returning to, having a common style greatly reduces maintainability costs. This blurb was borrowed from Adept Marketing’s entry on Linting; they just wrote it so well!

Unit Tests/Test Coverage:

Unit Tests lock in your assumptions of what your code does and doesn’t do. Whether your dev shop is pure TDD or simply TBP (test before push – yeah, I just made that up) having an acceptable level of unit tests (test coverage) in place creates confidence that you haven’t violated any previous assumptions while adding new features. It also frees your developers to refactor code whenever necessary. Having these checks automated helps your team to avoid building an insurmountable level of tech-debt.

Peer Reviews:

peer-review Performing peer reviews as the due course not only produces better code but, it also facilitates knowledge sharing and a sense of camaraderie. This is not a ‘got ya!’ or punitive activity. This is not the time to debate stylistic issues. This is a chance for a developer to share what they’ve written with the team and for the team to help catch mistakes before deploy: the best time to catch them. We use the Git Pull Request as our primary mechanism for performing peer reviews.

Static Code Analysis:

This check looks for things like the argument count, code complexity and methods that are too long or too similar: simply avoids bad smells from creeping into your code. Keeping your code base clean – and free of dead code – is super important to maintainability, modifiability and lowering the cost of ownership. For a deeper dive read the Wiki.

Integration Tests:

Easily executed – even better if automated – Integration Tests create the ultimate freedom to add to, modify, refactor and deploy your code. If your test suite is comprehensive you are confident that there will not be any surprises when your code hits the production environment. Our teams do not allow a story to be moved to complete or pushed to PROD until a QA team member has determined whether or not new Integration Tests need to be created.

test-in-prod

These barriers can sound onerous and sometimes seem frustrating but, what you will find is that your team will simply start coding to these standards and it will actually speed stories to done and ultimately to PROD due to increased confidence. When these steps are automatically enforced they become the base cost of writing software and paying these costs up front dramatically lowers the overall cost of ownership.