Manage Open Source Project using Continuous Integration and Continuous Delivery
Open sourcing a project means the project can be seen by anyone since it become public. Anyone can see, fork, modify and then contribute back to its main repository. It will be difficult to handle if project maintainers don’t have standard to contribute to the project.
Continuous Integration
Standard can be good to make another contributors follow our rules, even our coding styles. But how about the implementation? Are we sure that their implementation is correct ? The answer is we don’t have to be sure. We can make a additional protection layer to our implementation by using unit test or even instrumentation test. This can be automated using continuous integration(CI) tools. This is to make sure that every contribution don’t break our current implementation.
Continuous Delivery
Now that we are sure that implementation was not breaking by using CI, how can we manage release of our project? It’s a repeated task that will burden the project maintainers if they have to do it all times whenever there are changes in the project. That’s the purpose of continuous delivery(CD). We can automate the release but we still need the project maintainers work here. We have to design the project workflow before doing the automation. Here is the example of one of my project’s workflow.
Feature branch → Develop → Release → Master
- Master branch was only for released version of our project.
- Release branch was only for bridging the release to master branch. No other branch (even develop) can directly have a pull request to master branch (except for hotfix). Project maintainers don’t need to create a pull request to master branch. This was already done by our CD. Basically our CD check the Pull Request to release branch. If it pass unit test and instrumentation test then CD will create a new tag to release it and it was merged into master. Whenever a new tag created it will also deploy our release.
- Develop contains feature that’s already accepted by project maintainers. Project maintainers need to creating a pull request to release branch to make a release. The CD will manage the deployment when it’s already on release branch.
- Feature branch was contributors working branch. It must be created from current develop branch. When it finished, it also must be merged back to develop by creating a pull request back to develop.
To see the example, please take a look at my previous article. But please note in that article I was using different workflow (actually it’s outdated). But don’t worry. By reading that article you will understand how I manage every workflow using CircleCI.
Release Management
To make release management even easier, we can make milestones (it’s available at Github). Milestone can filter which feature, issues or pull request that is related to a release. You can take a look at this milestone or see a screenshot below.
By looking at it we already know that if two issues in this milestone was closed then we can make a release. We can also set the release due date on it so we know exactly when we will make a release.
