purpose

In developing a medium to large project, establishing a team workflow is essential. Corresponding to a certain product, from the initial product demand collection, analysis, modeling, interaction design, visual design, and then to the development and test team of the development team to test the delivered product, and finally go online, and quickly repair the problems of the online product. These processes involve collaboration between multiple teams and roles. The so-called no rules, no fangyuan. A workflow is formed by establishing norms for collaboration between teams and among team members. A reasonable workflow ensures that the product will not have too many problems from design to research and development to launch. A good workflow can improve the efficiency of r&d without making mistakes.

The r&d team

For the development team (Programmer), it is most straightforward to use a version management system for collaboration among internal members. Currently, SVN and GIT are commonly used to manage the code. More and more projects are switching from SVN to GIT, so GIT is the base on which to discuss the establishment of r&d team workflows.

Branch and environment introduction

In the process of project development, git source-based management will generally face the following problems:

  • How are the branches of the project managed
  • Which branch is published when the code is published to the machine
  • How to isolate multiple iterations of the same project

These problems are not independent, and the solution to one problem often affects the choice of solution to another problem.

For a product, there are different environments to release different branches of code before it goes live so that the code can be fully tested. Common environments are as follows:

  • online: The environment in which the product is finally released
  • stage: The environment used for final validation prior to product release, where the database is typically online and access is restricted
  • dev: The environment used during development
  • test: The environment in which the tester tests

Different environments use different branches when publishing. A project is generally divided into many different types of branches. The common classification method is to divide branches into the following types:

  • master
  • dev
  • feature
  • hotfix

In the case of the master branch, it corresponds to the code running on the machine, but when online, it does not necessarily use the master branch to online. The dev branch is the branch published to the dev and test environments. The Hotfix branch is the branch that handles urgent problems online. The feature branch is a branch used to develop a specific feature.

Discussion of several schemes

Branch online vs. trunk online

When A branch is launched, A branch (A) is separated from the master during development. When the branch code is launched, A branch code is put online, and then A branch code is merged back to the master. This strategy ensures the collision of multiple iterations on the same project at the same time, but you need to make sure that the merged master code on branch A is the latest code at launch, otherwise you may take functionality that someone else has launched offline (: And the branch A needs to be merged back to the master. Otherwise, the function will be offline when it is online next time (:

The main line is to use the master branch to go online, and the code on the line is the code on the master. When the code reaches the online standard, the code will be merged into the master to go online, and the development of new functions is also based on the code on the master. Therefore, based on the perspective of convenient management, the trunk online is the recommended way.

Single iteration vs. multiple iteration

How to manage the branch is a problem worth discussing under the scheme of trunk on-line. For a project, there may be only one iteration going on at a time, but there may be multiple iterations going on at the same time.

In the case of only one iteration, we can manage it according to the typical Git workflow with appropriate cuts. In terms of branch types, we can make the following specifications:

  • Master: Publish to the stage and Production environments
  • Dev: Published to the test environment
  • Feature/XXX: Development branch
  • Hotfix/XXX: Emergency bug fix branch

In the process, we can make the following restrictions:

  • The feature branch forks from the dev branch
  • In the development stage, only development is allowed on the feature branch
  • In the test stage, after the last round of test, if there are bugs that need urgent repair, development can be carried out on the Dev branch; in the rest stages, development can only be carried out on the feature branch
  • During the test, merge the feature branch into the dev branch
  • After all tests are complete, merge the dev branch to master before the stage environment
  • The code for both the Stage and Production environments is distributed in the Master branch code

Through these specifications, the repository code is kept the same for master and Dev, and the stage and Production environments use the same code.

The above process only works in the case of a single iteration, but when it involves multiple iterations at the same time, it becomes problematic.

How to manage workflow in multiple iterations at the same time?

It is natural to want to differentiate between multiple iterations, which leads to branching like this:

  • master
  • Iteration 1
    • Iteration 1 – dev
    • Iteration 1 – stage
    • Iteration 1 – feature
  • Iteration 2…

In this way, we still ensure that there is only one master for the entire project, and that the branch code is consistent with the online code. The rules for this approach are as follows, one iteration at a time

  • inmasterCheckout a new one with an iteration tag[iteration] - devBranch.
  • [iteration] - featureBranch from[iteration] - devPull in the branch,[iteration] - featureA branch is a branch that develops functionality and eventually needs to be merged into[iteration] - dev
  • [iteration] - devSince the branch is a test machine, there may be dirty code, so there is[iteration] - stageBranch, this branch goes frommasterCode pull, after the test is ok and then merge tomasterBranch, this method is also convenient to deal with the unexpected situation that the iteration suddenly does not go online in the last stage, to prevent rollbackmasterThere may be an impact on people working on other iterations.
  • hotfixBranches, because they deal with emergent problems, should be independent of the iteration and not placed in the iteration for processing.

This approach seems to be a reliable solution to multiple iterations on the same project.

One problem, however, is that with so many branches, it becomes cumbersome to manage.

Therefore, the process management process can be treated as a special case for rare unexpected situations, such as two iterations coming online at the same time. These special issues can be put into higher level project management, such as making arrangements with PMS not to go live at the same time.

It would be easy to redesign the multi-iteration code management process without considering these fewer problems. Similar to a single iteration, we have the following branches:

  • master
  • dev
  • hotfix
  • Iteration 1
    • feature/main
    • feature/xxx
    • feature/yyy
  • Iteration 2
    • feature/main
    • feature/xxx

A couple of differences

  • feature/mainIn thedevWhen you merge code, you don’t merge it, you merge itcoverThe code. This prevents additional iterations of code from being brought along.
  • feature/mainThe branch needs to be directly frommasterThe pull. And then on this basis to separate out the correspondingfeature[1~N].feature[1~N]It also needs to be merged back after developmentfeature/main

The workflow of this solution is as follows:

  1. Start development frommasterPull an iteration main branchfeature/main(The distinction between iterations can be prefixed and will not be detailed here)
  2. Developed features fromfeature/mainPull different onesfeaturebranch
  3. All functions will be combined into the testfeature/mainAfter the local test is okfeature/maincoverdevPublish to the machine
  4. After the test is completeddevIncorporated into themasterMachines in the development environment
  5. stageIf the environment is ok, the branch management for the rest of the machine is consistent with that for a single iteration. In this way, it can be easier inMultiple iterations of the same projectTo manage the situation.

conclusion

Workflow is designed to make development more efficient and less error-prone in a multi-party environment, and while flexibility may be sacrificed, it can be valuable in the long run.

More articles

github/fe-guide-book