Manuscript source: Alibaba Cloud Developer Community
Reasonable split warehouse
When we talk about warehouse management, we are actually not oriented towards a single warehouse, but a product, a project or even a business. There may be multiple warehouses behind this or there may be only one warehouse. Therefore, we should try our best in the early planning. To sort out clearly, the core avoids two misunderstandings:
Myth 1 : Build a warehouse for every responsibility
This solution may be the intuitive reaction of most people, but this method will rapidly increase the number of warehouses corresponding to the product, leading to a sharp increase in long-term management costs:
- Warehouse authority management is costly and easily confused
- High cost of code development submission
- Issues/PRs are too scattered and difficult to manage statistics
- ……
In fact, when ICE was in-house, we developed a lot of business components. Each business component is a separate warehouse. Then we recently gave it to me during a unified upgrade (caused by tools, specifications or other changes) Brings very big trouble:
- Some components (repositories) are no longer maintained but there is no mark
- Group permission management is too loose, leading to some components that have nothing to do with the official
- Need to switch warehouse operations frequently during the upgrade process
Therefore, we need to avoid overly fragmented management methods and make appropriate aggregations based on actual scenarios.
Misunderstanding 2 : All responsibilities are carried by a warehouse
In the front-end community, with the emergence of lerna, a batch release package tool, this method has become more and more popular, and some very popular projects such as babel , React , jest , etc. have gradually migrated to this solution. Putting aside the capabilities provided by the lerna tool, this aggregated management approach saves warehouse managers a lot of costs, such as:
- Only need to manage one warehouse
- Issue/PR/wiki , etc. are all converged to one place for management
However, when practicing this method, there may be deviations. I still use my ICE team as a negative teaching material. After stepping on the pit of Misunderstanding 1 , we decisively put all packages in the same warehouse when making the open source version. , And then use the directory structure to ensure clear responsibilities. This method also brings a lot of convenience to our management as mentioned above, but after a year of iteration, we currently encounter some problems:
- More responsibilities mean more codes, and with the growth of historical records, the speed of warehouse clone is not as good as day, especially in the slow network environment of some small companies (even if --depth is added )
- The directory structure is more complicated and not friendly enough to community students who are willing to contribute code
Therefore, we recommend that "on the basis of Option 2 , do another layer of splitting according to responsibilities." Combined with the alibaba/ice warehouse, we have split ice-devtools/ice-scripts/react-materials into independent warehouses through responsibilities . These Responsibilities of the warehouse are clear enough and related dependencies are aggregated together and not too scattered.
Establish operating specifications within the team
The author once had the honor to participate in the code specification formulation of the Taobao front-end team and the implementation of related tools. Therefore, I deeply understand the importance of the specification to the team. At the same time, there are some principles for formulating specifications:
(1) The specification first ensures the correctness, and secondly improves the quality;
(2) The specification cannot affect the efficiency too much (the trade-off between the two needs to be combined with the actual scenario).
Here are some of the specifications we are currently following:
Protect the branch !
Set the protection branch according to the warehouse situation. It is forbidden to submit code directly to the protection branch. Under very special circumstances, the admin account can bypass it.
New branch rule
- The branch name needs to have semantics, such as ice-scripts/fix-foo-bug
- If the requirements are relatively simple and the time period is relatively short, then directly cut a branch from the master , then merge to the master through PR , and release the version of the corresponding package after the merge
- If the demand contains multiple change points, such as iceworks release version, often involving multiple function points, the development cycle usually in about a week, if each PR are to master merge on, it is difficult to control the overall progress. Therefore, we have the following agreement:
a. First cut out the release branch from the master (such as release/iceworks-2.16.0 ), and then mention a benchmark PR . The PR needs to supplement the list of functions included in the current version and the release sequence, etc. This PR is mainly used to manage this time Version development progress, release branch is not allowed to push code directly, and there is no need to review when merging into master
b. Then each feature change cuts out a new branch from the release branch, and PR also needs to be merged into the corresponding release branch. The cut out branch does not need to contain version information (such as iceworks/fix-xxxx )
c. After all PR reviews are completed and merged into the release branch, release in the release branch, and then merge the PR of release -> master after the release is completed ( the reason why the release of the master branch is not here is that there may be various issues during release Problem, you need to make code changes again)
commit message specification
A good commit message can let people quickly understand the code intent, speed up the review process, and it will be more convenient for the history of the entire code repository in the future. There are enough specifications for this in the community to refer to, so I won’t repeat them here. Interests can refer to the reference link at the end.
PR merger process
Github provides three ways to merge PR by default . For the difference between the three ways, you can refer to the relevant link at the end of the article. We believe that Squash and merge should be selected in most cases , because squash will merge multiple commits of the current PR to make the entire submission The history is cleaner and clearer. However , it is recommended to use ordinary Merge when merging the above-mentioned release branch into master , so we need to keep those valid commit records at this time . At the same time , when the PR is merged , the Reviewer is responsible for rewriting the commit message to ensure more accurate semantics.
Here is a simple trace of history: in the earliest days, github did not provide a squash merge method. When we submit a PR to an open source warehouse, the submitter is generally required to merge the commit after the warehouse author’s review is completed , so many people There are keywords like "how to merge commit " on Google , but now you only need to click a button, which is also a manifestation of the efficiency improvement of tools.
Release process
For students of the management toolkit, they should be familiar with and follow the Semver specification (semantic version). This is the principle. On this basis, the following specifications should be followed:
Test version: The version number needs to follow the rules of xyz-n and is published through npm publish --tag beta . Many students, including the author, often forget --tag beta . I wonder if there is a more effective way to restrict it?
The official version directly via npm publish publishing
After the official version is released, you need to create the corresponding git tag at the same time , the tag naming rule: product name /xyz , such as ice-scripts/1.0.2 , and then fill in the Release information on GitHub