continuous integration – Clarifying the steps in a CI/CD, but namely if if unit testing should be done building a Docker image or before

I’m building at a Build and Deployment pipeline and looking for clarification on a couple points. In addition, I’m trying to implement Trunk Based Development with short-lived branches.

The process I have thus far:

  1. Local development is done on the main branch.

  2. Developer, before pushing to remote, rebases on remote main branch.

  3. Developer pushes to short-lived branch: git push origin main:short_lived_branch.

  4. Developer opens PR to merge short_lived_branch into main.

  5. When PR is submitted it triggers the PR pipeline that has the following stages:

    1. Builds the microservice.
    2. Unit tests the microservice.
    3. If passing, builds the Docker image with a test-latest tag and push to container registry.
    4. Integration testing with other microservices (still need to figure this out).
    5. Cross-browser testing (still need to figure this out).
  6. If the PR pipeline is successful, the PR is approved, commits are squashed, and merged to main.

  7. The merge to main triggers the Deployment pipeline, which has the following stages:

    1. Builds the microservice.
    2. Unit tests the microservice.
    3. If passing, builds the Docker image with a release-<version> tag and push to container registry.
    4. Integration testing with other microservices (still need to figure this out).
    5. Cross-browser testing (still need to figure this out).
    6. If passing, deploy the images to Kubernetes cluster.

I still have a ton of research to do on the integration and cross-browser testing, as it isn’t quite clear to me how to implement it.

That being said, my questions thus far really have to do with the process overall, unit testing and building the Docker image:

  1. Does this flow make sense or should it be changed in anyway?

  2. Regarding unit testing and building the Docker image, I’ve read some articles that suggest doing the unit testing during the building of the Docker image. Basically eliminating the first two stages in my PR and Deployment pipelines. Some reasons given:

    • You are testing the code and not the containerized code which is actually what will be run.
    • Even if unit testing passes, the image could be broke and it will be even longer before you find out.
    • Building on that, it increases the overall build and deployment time. From my experience, the first two stages in my pipelines for a specific service take about a minute and half. Then building and pushing the image takes another two and half minutes. Overall about four minutes. If the unit tests were incorporated into the Docker build, then it could possibly shave a minute or more off the first three stages in my pipeline.

    Would this be a bad practice to eliminate the code build and unit testing stages, and just moving unit testing into the Docker build stage?

Thanks for weighing in on this while I’m sorting it out.