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?

Improve this question

3 Answers 3

Reset to default
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.

Improve this answer
3
  • 2
    Good answer. Many people are not aware that with GitHub SaaS you can have circle-ci or another CI build the proposed changes in a pull request before the change is merged. So I have seen GitHub Enterprise on-prem used without that feature being used: the on-prem Jenkins Farm only runs once you merge the PR which may be broken unless the dev did a full merge and build. That then makes life way more complex. Years ago teamcity let you do a ci build on a farm before you even committed to prevent breaking a branch. Only building after the problem has been published is a legacy way of working.
    – simbo1905
    Jan 11, 2019 at 4:54
  • @simbo1905 all good, except PR verification is not 100% effective unless it's entirely serialized. Overlapping PRs means the respective changes don't take each-other into account and may still interfere with each-other causing a breakage when they land in the integration branch. Even if they don't have merge conflicts or even touch the same files - functional conflicts are still possible.
    – Dan Cornilescu
    Jan 16, 2019 at 3:13
  • @DanCornilescu Agreed PRs can pass independent builds but conflict. One renames a method, one adds code that uses the old method name. Both PRs pass builds in parallel. When both approved and merged the code won’t compile. Large projects use a merge bot like bors-ng. The reviewer doesn’t merge it they tell the bot to try. The bot does serial mergers only after a fresh build where it had combined what is in its merge queue. In our example it will try a merged build of the combined PRs. It fails so try only the first added to its queue, succeed, merge, then build and reject the other.
    – simbo1905
    Jan 16, 2019 at 5:52
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.

Improve this answer
1
  • This is so true: CI in my opinon should never run longer than it would on the dev's machine.
    – Ta Mu
    Jan 16, 2019 at 4:36
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.