Cakedc (cakephp Company) Git workflow--for larger teams large project development

Cakedc Git Workflow is a workflow for project development and release, in which the development and release cycles are based on several key phases (key phases):

• Development:

All active development activities are milestones driven, and outputs at this stage are very unstable code baselines

• Qa:

Quality assurance testing as part of a development cycle, primarily to assist in ensuring the satisfaction and quality of requirements

• Review

The customer or reviewer is faced with a stable code baseline that has been QA process and has been certified by QA Staff

• Release

The product of the release version after the QA and review review process has been successfully completed.

The workflow design used by Cakedc is based on the Gitflow recommendation of Vincent Driessen, although they have some similarities, but there are also partial cropping and modification, which may be more suitable for larger teams with formal process project development

Organization:

The main idea of the workflow design is that it can be used to integrate a QA process as part of their development process team or company, while providing customers with a stable stage server to review and approve the pending release. However, if you do not have a QA process, or if you do not provide stage server for customer Review/approve, these steps can be easily ignored.

Throughout the phase the entire development and release of our project is divided into several different stages of the goal, which we call milestones. A milestone itself is not equivalent to a release. A version of a project can consist of multiple milestone, depending on the project's planning and resource status.

These phases are represented by "permanent permanent" and "temporary temporary" branches, which, through these phase, advance our development process towards the right direction of a release. The reason for the need for a continuous branch is to prepare for various deployment requirements, allowing each individual to have a clear understanding of the state of the product at different stages of the project development. Both of these branches contain the following Git branches, which will form part of our work flow.

Permanent braches:

1.develop

Also known as the Bleeding Edge (frontier), this branch contains the already closed features prepared for the current milestone. This is an alpha-state code baseline that is often considered very unstable.

2.qa

All development activities for a milestone are eventually validated and tested on this branch. This is a beta-phase code baseline and is also considered unstable.

3.stage

Once you have passed the QA test for a development work done for a milestone, you can use this branch to host stable code base for review.

4.master

If the code for the previous stage branch is approval by the customer or reviewer, then the code for the Stage branch is merge to Master, and the master branch retains the current stable version of the project in the production environment.

Temporary branches:

1.feature

These branches are created from the develop branch to isolate the development work of a particular task. The definition of feature itself is often largely related to management style, such as milestone is a long or short sprints.

2.issue

These branches are created from the QA branch in order to solve the problem reported during the QA phase of the complete test of a milestone software

3.hot-fix

These branches are triggered by urgent problems reported in the production environment. In the best case, these branches will never be created, as we pass the QA process and the quality is well guaranteed

The important difference between "permanent" and "temporary" branches is that for permanent branches, the code commit code will never be modified directly on this branch, and the permanent branch will always get the relevant code through the merge temporary branch. The complete process is as follows:

In the following chapters, each phase of development and release phases will be described separately, detailing each process

Development:

In a milestone real-world development activity, developers will create feature from the Develop branch branch

These branches are named "Feature/xxx". XXX usually corresponds to a ticket in the project management system, such as

$ git checkout-b feature/1234-u Origin feature/1234

By isolating the development tasks to a separate branch, developers can effectively avoid destablize develop branches to avoid affecting others ' work. Moreover, if some feature are based on other feature, then this feature branch can be feature by other updated that have been commit to the develop branch (rebase)

If you and other developers are doing the same feature, then you can checkout their branches and work together.

$ git checkout-t origin/feature/1234

When a feature development is finished, it will be the merge back to develop branch, and the feature branch itself can be deleted.

--NO-FF feature/1234-D feature/1234$ git push origin:feature/1234

The develop branch itself is considered unstable, so it's best for developers to have a server that deploys this branch, so they can easily modify the project's bleeding edge version of Project, Assist in discussion or provide a way to review current progress. This also helps those who are not very clear about the development process to get the real state of the milestone that the project manager is going to arrive at.

Testing:

When a milestone is considered complete, the develop branch will be merge to the QA branch and the QA process starts:

It is important to note that when the develop branch is merge into the QA branch, all new features will constitute the next milestone. This allows for a complete parallelization of the current milestone test and the development of the next milestone. In addition, because the QA process is performed on a dedicated branch, this allows the test phase to be planned and executed without affecting the continuation of development.

--NO-FF Develop

During the testing phase, QA may find some issues of this milestone, that is, some feature are fail-off. When this happens, we are going to create the issue branch from the QA branch to solve these bugs. These branches are named "Issue/xxxx" and XXXX represents an ID in your project management or bug tracking system, such as:

$ git checkout-b issue/1234-u Origin issue/1234

When this issue branch survives, if the question itself depends on the end of another issue, then this issue branch itself can be done by other issue commits that have been made to the QA branch updated/ rebased. When the problem is resolved, merge to the QA branch, and the issue branch is deleted.

--NO-FF issue/1234-D issue/1234$ git push origin:issue/1234

In the QA phase, a dedicated test server should be required. This server deploys the code of the QA branch and is dedicated to the QA team for test use.

Review:

Once a milestone runs through the actual development activities and the QA process is completed, the new functionality can now be placed on the stage branch for review.

Here the QA branch will be merge onto the stage branch, and the QA branch needs to merge to the develop branch to use for future milestone:

--no---no-ff QA

Also, in order to mark the end of the milestone, you should make a tag from the stage branch, these tags are named "milestone/xxxx" XXXX is a milestone ID, usually an ordinal number.

$ git tag-a milestone/1

The stage branch can now be deployed to a staging server and can invite customers or reviewers to review and review. If any problems are discovered or new features are required at this time, then they will be the development tasks of the current active milestone on the develop branch, or they can be scheduled for future development tasks.

On the QA or stage branch, direct modification of commit is not allowed, only through the feature branch merge to the develop branch, and then through the QA process. It is important to respect the process, but many organizations may be able to patch directly on the stage branch, as this will disrupt the QA process.

Release:

When the stage branch passes the review, after completing one or more milestone, a release can be created. This will be the time the production server code is updated

The machine.

In order to create a Release,stage branch, merge to Master is required, and in order to create a release, a tag needs to be played on the master branch. These tags are named "release/xxx" xxx for version number.

--no--a release/1.1. 0

All code from QA merge to stage after this release constitutes the next version of the application.

Hot Fixes:

In a production environment, it is sometimes possible to find some major problems, and users can not wait until the next release to solve, then need to use the hotfix.

In this case, a Hot-fix branch needs to be created from the master branch, and these branches are named "hot-fix/xxx" xxx for BugID:

$ git checkout-b hot-fix/1234-u Origin hot-fix/1234

Depending on the requirements of QA, it may be necessary to solve the problem and then verify it on the Hot-fix branch. There are 3 methods:

1.Kamakazee: Here the Hot-fix branch is merge into the Master branch, and QA is tested directly in the production environment. This is a bad way, because inconsistencies in data can cause problems

2.Copycat: Here Hot-fix is merge to Master, and the master branch itself is staged to a dedicated server. If the production environment is based on the pushes to the repository or a scheduled build from the deployment, then

This may not be possible.

3.Paranoid: Here hotfix branch staged on a dedicated SERVER,QA must review the test before the merge to master. The staged server may need replicate the data used in the production environment. However, it may not be possible to do so due to legal issues or data privacy issues. Then an optional option is the direct stage on the production itself.

Once the patch itself succeeds, the Hot-fix branch must merge into the Stage,qa,develop branch.

--NO-FF hot-fix/1234--no-ff hot-fix/1234--no-ff hot-fix/1234  --no-ff hot-fix/1234

However, depending on the length of the milestones, it's possible that sufficient changes has been made in the pending re Lease the problem found in production have already been rectified, or the functionality surrounding the issue has been Modified to a point where the problem no longer exists, or have been altered completely.

Finally, once the hot-fix have been applied to all of the relevant branches it can now be removed.

$ git branch-d hot-fix/1234$ git push origin:hot-fix/1234

If you find that there is numerous bugs in your production environment This can is attributed to insufficient details at The requirements stage of the project, or an inefficient QA process. Keep in mind and the QA process is as good as the initial criteria and so validating the specification for a project is Key to it ' s success.

It ' s also worth noting that any developer who creates a "temporary" branch should remain responsible for it, as they is t He most likely candidates to know the status of the branch.

Cakedc (cakephp Company) Git workflow--for larger teams large project development