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
b. A remote and automatic build must pass on your feature branch content.
An alternative to conditions
bis to have one successful build on the merged content between the remote
masterand your feature branch you pushed.
Currently, our Continuous Integration pipeline is involving an additional branch:
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:
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?
It is best to pull only from
masterand not from
development. In rare (?) cases, developers will pull from
developmentbecause "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
masterbranch. In case the pull request will fail, they pulled the wrong commit and may get them in trouble later.
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
developmentso it is extremely hard to cancel now.
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
- 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:
- Eliminate all the cons I found earlier.
- Not wasting any time on reviewing a pull request which failed in the build process.
- Fewer branches, easier to understand the repository's history.