Pourquoi les entreprises utilisent-elles gitlab ? À quoi ressemble le flux de travail ?

Pourquoi les entreprises utilisent-elles gitlab au lieu de github et gitee ? L'article suivant présentera les raisons et parlera du workflow Gitlab. J'espère qu'il sera utile à tout le monde !

Qu'est-ce que

Terme officiel :

GitLab est développé par GitLabInc., en utilisant la licence MIT basée sur networkGit entrepôt Outils de gestion, Et possède wiki et fonctions de suivi des problèmes. Utilisez Git comme outil de gestion de code et créez un service Web basé sur celui-ci.

GitLab a été développé par les programmeurs ukrainiens Dmitriy Zaporozhets et Valery Sizov, et il est écrit en Langage Ruby. Plus tard, certaines parties ont été réécrites en Go Language. En mai 2018, l'entreprise comptait environ 290 membres d'équipe et plus de 2 000 contributeurs open source. GitLab est utilisé par des organisations telles que IBM, Sony, Jülich Research Center, NASA, Alibaba, Invincea, O'Reilly Media, Leibniz-Rechenzentrum (LRZ), CERN, SpaceX, etc.

GitLab a des fonctions similaires à Github, avec la possibilité de parcourir le code source, de gérer les défauts et les commentaires. Il gère l'accès des équipes au référentiel, facilite la navigation dans les versions validées et fournit une bibliothèque d'historique des fichiers. Les membres de l'équipe peuvent communiquer à l'aide du programme de chat simple intégré (Wall). Il fournit également une fonction de collecte d’extraits de code pour une réutilisation facile du code.

Pourquoi

Pourquoi les entreprises utilisent-elles gitlab au lieu de github et gitee ?

Quand il y a plus de versions d'un projet et plus de développeurs, la simple gestion de git pose encore de nombreux problèmes. D'une part, les développeurs ont trop d'autorité, et d'autre part, le personnel d'exploitation et de maintenance ne sait pas grand-chose. sur notre processus de développement, ils pensent donc à utiliser de meilleurs outils pour gérer les projets. J'ai donc pensé à gitlab.

CI/CD

CI/CD fait ici en fait référence à l'intégration continue (CI), à la livraison continue et au déploiement continu (CD) où les ingénieurs logiciels fournissent fréquemment des copies du code mis à jour à un emplacement partagé chaque jour. processus. Tous les travaux de développement sont intégrés à des heures ou à des événements planifiés, puis les tests et les travaux de construction sont automatisés. Grâce à CI, les erreurs qui se produisent au cours du processus de développement peuvent être découvertes à temps, ce qui non seulement accélère l'ensemble du cycle de développement, mais permet également aux ingénieurs logiciels de travailler plus efficacement. Et CD signifie Continu Delivery (CD), la deuxième pièce du puzzle pour la création d'applications de haute qualité. Le CD est une discipline de développement logiciel qui utilise la technologie et les outils pour fournir rapidement du code en phase de production. Une grande partie du cycle de livraison étant automatisée, ces livraisons peuvent être effectuées rapidement.

Nous présenterons le workflow CI/CD en détail plus tard

Contrôle des autorisations et collaboration

Le moyen le plus simple de travailler ensemble sur un projet GitLab est d'accorder aux collaborateurs des autorisations push directes sur le référentiel git. Vous pouvez ajouter des rédacteurs à un projet via la section "Membres" des paramètres du projet et associer le nouveau collaborateur à un niveau d'accès (. En donnant à un collaborateur "Développeur" ou supérieur Avec le niveau d'accès, cet utilisateur peut directement s'engager dans le référentiel ou succursale sans aucune restriction.

Une autre façon de rendre la collaboration plus découplée consiste à utiliser des demandes de fusion. Son avantage est qu'il permet à tout collaborateur pouvant voir le projet de contribuer au projet de manière contrôlée. Les collaborateurs disposant d'un accès direct peuvent simplement créer une branche, s'engager dans cette branche ou ouvrir une demande de fusion vers master ou toute autre branche. Les collaborateurs qui ne disposent pas d'autorisations push sur le référentiel peuvent « fork » le référentiel, s'engager sur cette copie, puis ouvrir une demande de fusion de cette copie vers le projet principal. Ce modèle donne au propriétaire du projet un contrôle total sur les engagements effectués dans le référentiel et sur le moment où les contributions de collaborateurs inconnus sont autorisées. (C'est un peu similaire à github, mais actuellement les bibliothèques privées github sont payantes)

La fusion des requêtes et des problèmes dans GitLab est une partie importante d'une discussion de longue date. Chaque demande de fusion permet une discussion sur la ligne où le changement a été proposé (ce qui permet une révision légère du code), ainsi que sur un sujet global. Les deux peuvent être attribués aux utilisateurs ou organisés dans une interface de jalons.

Cette section se concentre principalement sur les fonctionnalités liées à Git dans GitLab, mais en tant que système mature, GitLab propose de nombreux autres produits pour vous aider à travailler ensemble, tels que des wikis de projet et des outils de maintenance système. L'un des avantages de GitLab est qu'une fois le serveur opérationnel, vous aurez rarement besoin d'ajuster les fichiers de configuration ou SSH dans le serveur ; la plupart de la gestion et de l'utilisation quotidienne peuvent être effectuées dans l'interface du navigateur.

Introduction au workflow Git Flow

De manière générale, les projets dans une entreprise sont développés par plusieurs personnes en même temps, la manière de gérer les branches git est donc devenue une question clé.

Donc ici, nous devons présenter notre workflow git flow.

Commençons par l’environnement d’exécution du code. De manière générale, l'environnement dans lequel le code s'exécute est que l'équipe de l'entreprise disposera d'au moins un de ces environnements :

• Environnement de développement local : Pour les tests des développeurs, il peut s'agir d'un serveur statique déployé localement, ou bien sûr Cela peut être similaire à un environnement similaire à l'exécution du serveur npm. Le code exécuté dans l'environnement local peut être n'importe quelle branche
• environnement de développement dev : cet environnement est déployé à l'aide du code produit par la branche de développement dev et est le seul public. . L'environnement de test et de pré-version
• : Cet environnement est déployé à l'aide du code produit par la branche de développement release Le seul public
• Environnement de production en ligne : Cet environnement est produit à l'aide de la branche de développement master Pour déployer le code, le seul public.

le modèle de branche git correspondant est comme ceci

et la stratégie de branche correspondante est comme ceci

• master : branche protégée, correspondant à ⽣ Branche de l'environnement de production
• release : Branche de protection, toutes les branches développées demandent à être fusionnées dans la branche release, fournie aux testeurs pour les tests
• feature-* : Branche de fonction, développement de fonctions spécifiques
• dev/ test-* : branche de développement & branche sale, correspondant à l'environnement de développement partagé par tous . Le code ci-dessus sera déployé dans un environnement de développement public pour que les développeurs effectuent des auto-tests et effectuent certaines tâches quotidiennes, Débogage quotidien
• hotfix-* : branche de réparation d'urgence de bug, qui peut être directement fusionnée dans le maître (. Si la version fusionne plusieurs branches de fonctionnalités, lors des tests, il s'avère que le buf a besoin d'une réparation d'urgence, et la réparation d'urgence une fois le test terminé, il peut être directement fusionné dans la version principale. release est fusionnée dans le maître, les fonctions qui sont en cours de test ou celles qui ne sont pas encore prêtes à être lancées seront lancées directement)

Introduction au workflow

• Recevoir le document d'exigences, réviser et assigner chaque personne ou groupe au développement des fonctions. Le personnel concerné vérifiera les points de fonction du maître

• En plus des tests locaux pendant le développement, si nécessaire, il sera fusionné dans la branche de développement et testé en public. environnement de développement

• Parce que lors du développement des fonctions, des correctifs peuvent être fusionnés dans le maître, lors de la fusion du code, il est d'usage de fusionner dans le maître pour éviter ⽌Conflits, etc.

• ⾃Une fois le test terminé. , demandez la fusion dans la version. Une fois la fusion réussie, déployez dans l'environnement de test et demandez au testeur de faire le test

• Une fois le test réussi, l'application de version est fusionnée dans master et prête à être mise en ligne

.

• Si le test échoue, fusionnez à nouveau après la modification de la branche de fonction

• Supprimez la branche de fonction correspondante une fois qu'elle est en ligne réussie et stable, et que le développeur fusionne la dernière branche principale

(Partage vidéo d'apprentissage : Vidéo de programmation de base)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!