Code review process

Date adopted: 
August 28, 2020
Last update: 
August 28, 2020

What does code review mean?

Code review is the process where have a 3rd party examine code to identify issues. This ensures we deliver quality services and websites. It also helps build capacity among our vendors so they can produce code that meets the government's requirements.

We take this collaborative approach to make sure the code meets the government's standards and your final product works and looks the way it should.

We are working toward giving developers tools to run quick code quality audits to check against our standards.

Onboarding vendors

eServices onboards all vendors on the eServices Standing Offer Agreement (SOA) list. They're aware that code review is part of our service delivery process.

Once you've hired a developer and they begin work on your project, eServices will meet with them to determine how a service or website should be built and what approach the developer should take. This includes agreeing on how we'll tackle code reviews for your project.

Timing your code reviews

Code review occurs before we deploy your service or website to User Acceptance Testing (UAT) and Prod, or the live website. There can be more than 1 round of review.

This process can anywhere from a few days to 2 weeks depending on the quality and complexity of the code.

Hiring a 3rd party to review code

eServices will work with the client and developer to determine how many rounds of review your project will require. We'll then reach out to a 3rd party to get an estimate for this work.

The department will approve the code review budget and eServices will get the contract in place.

After your code review

Once the code review is complete, the 3rd party reviewer will share notes with the developer and eServices. We'll work together to determine roles for addressing the feedback.

Once the issues are addressed, and the client department is satisfied, eServices will work with the developer to deploy the fixes.

How to manage issues

Any issues should be documented and communicated to eServices as Git issues. Development partners are expected to address all issues.