When we talk about automating the development and testing process, it might sound like it’s a very ambitious affair, and indeed it is. But if you break it into pieces, then individual fragments of the whole picture become visible. This process of fragmentation is highly important in two situations:
- when actions that require concentration and accuracy are being performed manually;
- when there are severe time constraints.
In our case, the time constraint is evident: releases are compiled, tested, and rolled out to the production server twice a day. Given the cramped time periods in a release’s life cycle, the process of deleting (rolling back) a buggy task from the release branch has great significance. And to realize that process, we use git rebase. Because git rebase is an entirely manually operation that requires attentiveness and exactness, and takes an extended period of time, we have automated the process of deleting a task from the release branch.
Git is currently one of the most popular version control systems, and we use it effectively at Badoo. Working with Git is quick and simple.
A particular feature of our model is that we develop and test each job in a separate branch. The branch name consists of the JIRA ticket number and an arbitrary description of the job. For example:
We compile the release and test from a separate (release) branch in which finished and tested jobs are merged in the development environment. Because we roll out code to our production server twice a day, it follows that we create two new release branches every day.
The release is formed by merging jobs into a release branch using the auto merge tool. We also have a master branch, which is a copy of the production server. After the release and each individual job have been integration tested, the code is sent to the production server and merged into the master branch.
When a release is being tested in the staging environment and a bug is found in one of the jobs but there is no time for a fix, we simply delete that job from the release using git rebase.
Note: We do not use the git revert function in the release branch, because if a job is deleted from the release branch using git revert and the release branch is merged into the master branch, from which a developer then pulls fresh code into the branch where the bug originated, then he would have to do a revert on a revert in order to back out his changes.
In the next stage, we build a new version of the release, push it to the staging environment, test for bugs, run autotests, and then, if the tests pass, we push the code out to the production server. The main elements of this flow are entirely automated and operate in a seamlessly integrated process (until now only deleting a job from the release branch was performed manually).
#Statement of the problem
Let’s consider what can be used to automate the process:
- The release branch, which we are planning on pulling a ticket from, consists of two kinds of commits:
- A merge commit that happens when merging working branches into the release branch and contains the ticket name in the commit message, since branches are named with a job prefix;
- A merge commit that happens when automatically merging the master branch into the release branch. We apply patches in a semi-automated fashion to the master branch using our special DeployDashboard tool. Patches are applied to the appropriate ticket. Furthermore, the ticket number and patch description are given in the commit message.
- The built-in git rebase command, which is best used interactively because of the useful visualization.
Problems you may encounter:
- During the git rebase operation, a remerge of all commits in the branch is performed, beginning with the one being rolled back.
- If a merge conflict was resolved manually when the branch was created, Git does not save the resolution in memory. So when running git rebase, you will have to fix merge conflicts again manually.
- In this particular algorithm, conflicts are divided into two kinds:
- simple - these conflicts occur because the version control system does not support remembering previously resolved merge conflicts;
- complex - these conflicts occur because code was changed in a specific line (file), not only in the commit being deleted from the branch, but also in subsequent commits, which are remerged when git rebase is run. In this case, the developer fixes the conflict manually and performs a push into the release branch.
Git has an interesting feature, “git rerere”, which remembers the resolution of conflicts during a merge. It is enabled in automatic mode, but unfortunately it cannot help us here. This function only works when there are two long-standing branches that are constantly being merged. Git remembers these conflicts without any trouble.
We only have a single branch and if the -force function isn’t used when git pushing changes into the repository, then after each git rebase you have to create a new branch with a new trunk. For example, we apply the suffix _r1,r2,r3 … after each successful git rebase operation and perform a git push of the new release branch into the repository. Thus, the conflict resolution history is not preserved.
What do we ultimately want to achieve?
By clicking a certain button in our bug tracker:
- The job is deleted from the release automatically.
- A new release branch is created.
- The job’s status is changed to Reopen.
- All simple merge conflicts are resolved in the process of deleting the job from the release.
Unfortunately in any workflow it is impossible to resolve complex merge conflicts, so if a complex conflict occurs we notify the developer and release manager.
- Our script uses an interactive rebase and captures the commits in a release branch that has the job number to be rolled back.
- Upon finding the desired commits, the script deletes them and remembers the names of the files they affected.
- Then it remerges all commits, beginning with the commit we most recently deleted in the branch’s trunk.
- If a conflict occurs, then it checks the files involved in the conflict. If these files match the files of deleted commits, then we notify the developer and release manager that there has been a complex conflict that must be resolved manually.
- If the files do not match and there is a conflict, then it is a simple conflict. Then we take the code of the files from the commit, where the developer already resolved this conflict, from the origin repository.
Thus, we “run to the root of the branch”.
The probability that we will hit a complex conflict is almost non-existant, i.e. this process will execute automatically 99% of the time.
Now let’s take a step-by-step look at what our script will do (in the example, only an automatic rebase is used and the script can simply be used in the console):
- We purge the repository and pull the latest version of the release branch.
- We get the top commit in the trunk with a merge in the release branch that we want to revert. a. If there is no commit, we report that there is nothing to revert.
- We generate an editor script that only deletes hashes of merge commits from the branch’s trunk, thus deleting them from the history.
- In the reverter script’s context, we specify the editor script (EDITOR) that we generated in the previous step.
- We run git rebase -ip for the release. We check the error code.
- If it is 0, then everything succeeded. We jump to step 2 to find potential prior commits of the working branch being deleted.
- If it is not 0, then there was a conflict. We try to resolve it:
- We remember the hash of the commit that could not be applied. It is stored in the file .git/rebase-merge/stopped-sha
- We examine the output of the rebase command to determine what went wrong.
- If Git reports “CONFLICT (content): Merge conflict in “, then we compare the file with the version prior to that being deleted, and if it is the same (the was not changed in the commit), then we simple take the file from the build branch’s root and commit. If it differs, then we exit and the developer resolves the conflict manually.
- If Git reports “fatal: Commit is a merge but no -m option was given”, then we simply repeat the rebase with the –continue flag. The merge commit is skipped, but the changes are not lost. This usually happens with the master branch, but it has already been pulled into the root of the branch and this merge commit isn’t needed.
- If Git reports “error: could not apply… when you have resolved this problem run ‘git rebase –continue’”, then we run git status to get a list of files. If even one file from the status is in the commit that we are rolling back, then we skip the commit (rebase –skip) that we remembered in step 5.b.i, writing this fact to the log in order to notify the release manager and let him or her decide whether this commit is needed.
- If none of the above happens, then we exit the script and report that something unexpected occurred.
- We repeat step 5 until we get exit code 0 or the cycle counter > 5, in order to avoid an endless loop.
Ultimately, we created a script that automatically deletes jobs from the release branch. We saved time in compiling and testing the release and almost entirely eliminated the human factor.
Of course, our script isn’t suitable for every Git user. In some instances it would be simpler to use git revert, but it’s best not to get carried away with that command, e.g. reverting a revert of a revert… We hope that the difficult git rebase command is now more understandable to you. And if you use git rebase regularly, we hope our script will work for your development and release process.
Ilya Ageev, Head of QA