-2

I'm designing a continuous integration pipeline using Bitbucket & Jenkins with only master and feature branches. I'm failing to find convincing arguments to the fact that my design is better.

* Our Build process includes compiling frontend and backend code (same repository), run fronted and backend unit tests & Cucmber, frontend end-to-end tests, backend load testing.

From my perspective, one of the most important parts in it, is to have 2 conditions before a pull request can be approved:

a. A feature branch, which you pushed, must contain the latest commit from the remote master branch.

b. A remote and automatic build must pass on your feature branch content.

An alternative to conditions a and b is to have one successful build on the merged content between the remote master and your feature branch you pushed.


Currently, our Continuous Integration pipeline is involving an additional branch: development.

Lack of experience with webhooks or wanting things to be done a certain way made my co-workers design a CI in which we pull requests to the development branch and as soon as our Jenkins server finds out that the development branch has been updated (by asking every X seconds), it runs a new build.

If the build succeeds, the job is also forwarded to the remote master by merging between him and development. Otherwise, if the build fails, nothing happens.


I'm facing 2 problems. The first is to find convincing arguments to the devops team, who is responsible to design our CI system, because from my understanding, my solution will involve additional learning and over all, much more time to finish. I think that in reality, devops teams does not have the same interests as our developer teams because in the bottom line, they don't use the products they design or build for the development teams.

The second and last problem is to find convincing arguments to managers who can change things. It's extremely hard for me to convince a person who does not have any technical skills with Git, Continuous integration models, Bitbucket and so on: "Github and Bitbucket are exactly the same". I'm getting the same response every time: "It's working for now, and your solution may be better but it needs too much effort to accomplish and does not add a real business value at the moment".


The cons I found so far for the old design:

  1. Everyone has read permissions to remote development. It may include commits which belong to pull requests with failed builds. It means that I can't know or trust any commit in that branch's history if it contains valid content or not. Then why do I need to see this branch in the repository history?

  2. It is best to pull only from master and not from development. In rare (?) cases, developers will pull from development because "they know that the build won't fail for this particular pull request" so there is no reason to wait until that content will be available from remote master branch. In case the pull request will fail, they pulled the wrong commit and may get them in trouble later.

  3. In case a pull request is approved and the build passed, then for some reason (a bug or bad design), we want to "go back" (this is available in Github and Bitbucket) and cancel the last pull request, now I need to revert 2 branches instead of one. Also there may be multiple people pulling from master and development so it is extremely hard to cancel now.

  4. Bitbucket offers lots of webhooks we can use, why not to use them instead of pulling every 2 seconds from Jenkins to Bitbucket if one specific event happens (commits were added to the development branch):

    • Repository: Push,Fork,Updated,Commit comment created,Build status created,Build status updated.
    • Issue: Created,Updated,Comment created
    • Pull Request: Created,Updated,Approved,Approval removed,Merged,Declined,Comment created,Comment updated,Comment deleted

The pros I found so far to my design:

  1. Eliminate all the cons I found earlier.
  2. Not wasting any time on reviewing a pull request which failed in the build process.
  3. Fewer branches, easier to understand the repository's history.

How would you describe the importance of this kind of change in our CI?

  • 5
  • @gnat Not accurate. I'm trying to explain to devops & managers. – CantBeTooSure Dec 9 '17 at 13:31
  • 2
    @CantBeTooSure that's just a value of ${someone}. Also note that impotence is really not the same as importance. – jonrsharpe Dec 9 '17 at 13:37
  • 2
    There isn't really anywhere on Stack Exchange that caters to "how do I convince someone of something." At the end of the day, the benefits of your change have to exceed the costs. By the way, I think you meant "importance," not "impotence." – Robert Harvey Dec 9 '17 at 17:21
  • 1
    You don't really explain what your "better designed" CI pipeline actually is. It is hard for people to provide input without knowing what changes you are actually proposing to make. And if you did explain your design here, you could phrase your question as "what are the relative pros and cons of these two aproaches?" Which is a much better format for this site – Caleb Dec 10 '17 at 12:25
2

Honestly your current process doesn't sound that bad.

You are building and running tests against dev rather than feature branches. But this is fairly common and shouldn't be a problem for small features.

You are using a polling workaround rather than hooks, but the user cant tell the difference.

If you magically had everything you want, would the system be that different overall? I think you are failing to find convincing arguments because your cons just aren't that bad.

The only thing that bothers me slightly is the auto merge to master when the tests pass.

  • I can't understand how a workaround is acceptable solution for an oranization. – CantBeTooSure Dec 9 '17 at 18:26
  • the only cost in this case is internal bandwidth. why would that make it unacceptable? – Ewan Dec 9 '17 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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