8

My company is integrating CI/CD, so far we have implemented CI from what I understand. Currently when a developer pushes code to our git repo, the CI pipeline runs.

Currently our CI pipeline include building the project and the doing static code analysis to make sure it meets our coding standards. We will be implementing testing next. The build and static code analysis take about 3mins right now. From what I have read fixing issues right away is critical to CI/CD. I expect when we add in unit tests that the pipeline could take around 10mins to run.

So my question is when a developer make a pull/merge request should they wait for the CI pipeline to complete or just move on to the next task and come back to fix pipeline issues if they exists? Or should they sit and watch the pipeline run?

030
  • 13,383
  • 17
  • 76
  • 178
iqueqiorio
  • 181
  • 4

3 Answers3

7

Sit and watch the pipeline run?

No, that is not how you work efficiently.

Developers push their commits to the source control repository and then the CI/CD pipeline is triggered.

Developers may post a well-written pull request anytime they want. There is usually a visual mark representing an "on-going build"/"failed build"/"successful build".

Typically a brach can be merged whenever all these criteria is fulfilled:

  • at least one approver / or as many that is required to approve has approved.
  • a "successful build"
  • no unresolved merge conflicts

If any of these criteria not is fulfilled, they need to be fixed, but the developer does it whenever he has time or priority to do this task.

Jonas
  • 1,045
  • 6
  • 9
1

I recommend trying your best to ensure the pipeline is less than 10 minutes. You can execute your tests in parallel to enable this. As jonas answered they can then spend time creating a pull request (while the pipeline is running).

Context switching is bad for productivity so rather than picking up another task, I recommend the developer use that time to work on anything else related to the change he just made. Maybe there’s some documentation that could be updated related to this. If it’s a noteworthy feature he could create a short gif showing how to work with it. Even looking at their code change again may help them think how they could improve it next time. This time could also be used in reviewing other developers pull requests and code changes.

If they move onto developing another feature in that 10 minutes it’s likely it’ll be longer than 10 minutes before they get back to it and the work will be less fresh in their mind. If the CI then fails, it will be harder for them to remember what could have gone wrong and fix the code.

Samuel Garratt
  • 111
  • 1
0

Ok so let's assume you have version control tool as Git and CI tool Jenkins. So Dev creates a feature branch for a issue. You have a multibranch pipeline or a workflow in your CI tool which detects this feature branch in next scan and executes the CI steps.

So things which must be ensured are:

  1. Before raising PR/MR, the CI job is green. If it is not green, PR/MR should not be raised. Obviously the developer can perform other tasks and then come back and fix issue on this task, that is their choice depending upon task priority. You can even control any PR from being raised by checking it's CI parameters.(If you do not trust your dev that much and they continuously raise PRs for broken builds)

  2. Once PR is raised, a code reviewer will review and merge if everything is OK. Code reviewer can be any other developer. His/her responsibility is to review the code, see if it is within the criteria of "Definition of Done". DoD is mainly an agile term but agile and DevOps go hands in hand.

  3. Once code is merged the CI for main branch should be green. If not, code should be rolled back and issue should be fixed because generally main branch is also deployed to environments and not rolling back means whole environment will be broken.

Obviously, post build actions will notify the committer that Hey, you have broken the build, so Devs can perform their other tasks, they will get emails anyways.

deosha
  • 253
  • 1
  • 7