Here I have another case of writing codes on a feature branch and merging it back (in Chaos Mesh).
Actually there are a lot of problems inside, not only the branch management and feature development, but also version management, product design… My workmates have all suffered a tiring month and I’m really regretful for the bad working experience and the difficulties I have brought.
Here is the final PR. chaos-mesh#1908. It aims to redesign the cron chaos experiments, split into multiple controllers and fix some historical bugs (which could be fixed naturally after this refractor). I don’t know whether it’s off-topic as it’s not only a feature, but also a refractoring.
Besides the advantages @wjhuang2016 has talked, I have faced a lot of problems:
Fast Iteration with cost
I don’t know how @wjhuang2016 managed to achieve both quickly iteration and well-tested, because even in the feature branch, we have to wait for PR to get reviewed and merged. In Chaos Mesh, I have to say these PRs in the feature branch are not well reviewed. A lot of PRs are reviewed by only one developer, to ensure we can move on as fast as possible. And some of these PRs are also not well tested (though we added some tests later).
Merging master is really hard
To make it not too difficult to merge feature branch back to the master, we have to merge master into the feature branch periodically. However, it could be difficult. While you are developing new features, there are also some more features merged into master and they are conflict with the feature branch. You don’t know how to test these features and don’t know how to fix them.
Feature branch is really not friendly for big refractoring, which may change the code structure, copy some codes to another place, etc… Is there any way to refractor progressively? However, refractoring is really needed, with the thought and understanding of developers get deeper. When Chaos Mesh booted, I and @cwen are all green hand on cloud and kubernetes, and we don’t know how to design a good structure or manage an extensible software on kubernetes. But every software should have a second chance (or third chance, forth chance) to remedy the old design mistakes, right?
Version Management and Compatibility
In this feature, compatibility will be broke. Someone told me “not to break compatibility” in middle version, but all versions are checked out directly from master. Therefore, this feature cannot be done before “1.2.0” release (which is the last version of Chaos Mesh 1), and should be merged in Chaos Mesh 2.0.
However, “1.2.0” is released at 23, April, and “2.0” should be released before June, which leaves us really short time to develop and test. I started to develop this feature at around 10, April.
Without rich time, every developers (and the tests and documents) are getting really tired and chaotic . After my developing, my teammates should do their following job like exporting HTTP API, modifying frontends… The time left for them is even much tighter and the work experience is not so well (regarding the lack of documents, tests and product designs). The schedule becomes out of control and we have to delay, and delay again.