Does your business depend on open source software? Did you change the software to adjust it to your needs? What are you going to do when a new version of the software is released? How are you going to keep up with the new releases?
This is a problem that we are facing right now. And we think (theoretically at least) that we found the solution to it.
Solution involves using Git.
Taking into consideration the image above. We have 2 branches on Git. We will call them Master and Dev. The Diff Patch is just a diff(only the differences are saved in the patch file) between Dev and Master.
Steps to keep up with the constant releases of new versions:
The first step: We download and install the version of Open Source Software that we are currently using. After that we push the code to a Git branch – in our image Master (is called Clean I).
The second step: We push to another Git branch the current open source software with the changes that we made – in our image Dev Branch (is called Clean I + Changes I).
The third step: We make a Diff Patch using Git between the branch that has our changes and the one that has only the clean install – in our image Dev Branch – Master.
After some time a new version of the Open Source Software is released and we need the new security fixes or the new features. But we can’t afford to loose the changes that we did. What can we do?
The forth step: We make the update or we do a clean install of the new version. Then we push the files to the same Git branch as the other clean install – in our case Master.
The fifth step: We use a copy of the same clean install and push the Diff that we created in the Third step (Changes I). We also can make other required changes (Changes II). We test all the changes. If everything is fine we push the files to the same branch where we previously pushed the changed code – in our case Dev Branch.
The sixth step: Again we make a diff between the branch that has the changed code and the one that has the original code.
What we need to take into account:
1. The diffs that we are making in the steps three and six should be done after we finish and test all the changes that we need in steps two and five. Better to do it just before pushing the diff over the clean code.
2. We always need to have a clean install in one of the branches of Git so we can create the diffs. The clean install should be of the current used version of the Open Source Application.
3. Unit or UI or Functional tests should be done to make sure the custom functionality that we implemented is still available after update. It is recommended to have Automated Tests in place. Or at least to note down the tests that should be carried out manually in the future. So after a new update you or someone else in your team will know what to test after the update.
Note: this is only theoretical. We did not had the time to implement it yet. But we will be back with a more extensive and technical article after implementing it.