Why do companies use gitlab? What does the workflow look like?

Why do companies use gitlab instead of github and gitee? The following article will introduce the reasons and talk about the Gitlab workflow. I hope it will be helpful to everyone!

What is

Official saying:

GitLab is a Gitwarehouse management tool developed by GitLabInc. using the MIT license based on the network and has wiki and issue tracking function. Use Git as a code management tool, and build a web service based on this.

GitLab was developed by Ukrainian programmers Dmitriy Zaporozhets and Valery Sizov. It is written in the Ruby language. Later, some parts were rewritten in Go language. As of May 2018, the company had approximately 290 team members and more than 2,000 open source contributors. GitLab is used by organizations such as IBM, Sony, Jülich Research Center, NASA, Alibaba, Invincea, O’Reilly Media, Leibniz-Rechenzentrum (LRZ), CERN, SpaceX, and more.

GitLab has similar functions to Github, with the ability to browse source code, manage defects and comments. It manages team access to the repository, makes it easy to browse committed versions and provides a file history library. Team members can communicate using the built-in simple chat program (Wall). It also provides a code snippet collection function for easy code reuse.

Why

Why do companies use gitlab instead of github and gitee?

When there are more versions of a project and more developers, simple git management still has many problems. On the one hand, the developers have too much authority, and on the other hand, the operation and maintenance personnel do not understand our development process very well, so Thinking about using better tools to manage projects. So I thought of gitlab.

CI/CD

CI/CD here actually refers to continuous integration (CI), continuous delivery, and continuous deployment (CD). CI is what software engineers do every day. The process of frequently delivering copies of updated code to a shared location. All development work is integrated at scheduled times or events, and testing and build work are then automated. Through CI, errors that occur during the development process can be discovered in time, which not only speeds up the entire development cycle, but also makes software engineers work more efficiently. And CD stands for Continuous Delivery (CD), the second piece of the puzzle in creating high-quality applications. CD is a software development discipline that uses technology and tools to quickly deliver production-stage code. Because much of the delivery cycle is automated, these deliveries can be completed quickly.

We will introduce the CI/CD workflow in detail later

Permission control and collaboration

The easiest way to work together on a GitLab project The method is to give collaborators direct push permissions to the git repository. You can add writers to a project through the "Members" section of the project settings and associate the new collaborator with an access level (. By giving a collaborator "Developer" or higher With an access level, this user can directly commit to the repository or branch without any restrictions.

Another way to make collaboration more decoupled is to use merge requests. Its advantage is that it allows any collaborator who can see the project to contribute to the project in a controlled manner. Collaborators with direct access can simply create a branch, commit to this branch, or open a merge request to master or any other branch. Collaborators who do not have push permissions on the repository can "fork" the repository, commit to the copy, and then open a merge request from that copy to the main project. This model gives the project owner complete control over what commits are made to the repository and when contributions from unknown collaborators are allowed. (This is somewhat similar to github, but currently github private libraries are charged)

Merging requests and issues in GitLab is a major part of a long-standing discussion. Each merge request allows discussion on the line where the change was proposed (which enables a lightweight code review), as well as on an overall topic. Both can be assigned to users, or organized into milestones interface.

This section mainly focuses on Git-related features in GitLab, but as a mature system, GitLab provides many other products to help you work together, such as project wikis and system maintenance tools. One of the nice things about GitLab is that once the server is up and running, you will rarely need to adjust configuration files or SSH into the server; most management and daily use can be done within the browser interface.

Git Flow workflow introduction

Generally speaking, a project in an enterprise is developed by several people at the same time, so how to manage git branches becomes An important question.

So here, we need to introduce our git flow workflow.

Let’s start with the running environment of the code. Generally speaking, the environment in which the code runs, the company team will have at least the following environments:

• Local development environment: self-tested by developers, It can be a static server deployed locally. Of course, it can also be an environment similar to running npm server. The code running in the local environment can be the
• dev development environment of any branch: This environment is used for development The only public
• test & pre-release environment is deployed using the code produced by the development branch dev. This environment is deployed using the code produced by the development branch release and is the only public environment. The
• online production environment: This environment is deployed using the code produced by the development branch master. The only public

corresponding git branch model is The corresponding branch strategy of

is like this

• master: protect the branch, corresponding It is the branch of the production environment
• release: protected branch. All developed branches will apply to be merged into the release branch and provided to testers for testing
• feature-*: function Branch, specific function development
• dev/test-*: development branch & dirty branch, corresponding to the development environment shared by everyone, the above code will be deployed to a public development environment , for developers to do self-tests and cope with some daily and non-daily debugging
• hotfix-*: bug emergency repair branch, which can be directly merged into master (if the release merges several features Branch, while testing, discover buf that needs emergency repair. After the emergency repair test is completed, it can be directly merged into master. If merged into release, then merged from release into master, those functions under testing may not be ready to go online yet. The function will be launched directly)

Workflow introduction

• Receive Requirements document, after review, each person or group is assigned to function development. Relevant personnel check out the function branch from the master.

• During development, in addition to testing locally, If necessary, it will be merged into the dev branch, and you can do your own testing in a public development environment

• Because during the development of functions, there may be hotfixes that are merged into the master, and the code is merged It is a habit to merge the master to prevent conflicts.

• After the self-test is completed, apply to be merged into release. After the merge is successful, deploy it to the test environment and notify the tester to do the test

• After the test passes, the release application is merged into the master and is ready to go online

• If the test fails, merge again after modifying the functional branch

• After successful and stable online, delete the corresponding functional branch, and dev merges with the latest master branch

(Learning video sharing: Basic Programming Video)

The above is the detailed content of Why do companies use gitlab? What does the workflow look like?. For more information, please follow other related articles on the PHP Chinese website!