patterngitMinor
Should developer wait for CI pipeline to complete or start next task after pushing
Viewed 0 times
afterwaitstartnextcompletefordevelopershouldpipelinepushing
Problem
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?
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?
Solution
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:
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.
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.
Context
StackExchange DevOps Q#5940, answer score: 7
Revisions (0)
No revisions yet.