なぜ企業は gitlab を使用するのでしょうか?ワークフローはどのようなものですか?
- 青灯夜游転載
- 2023-03-23 19:49:071986ブラウズ
なぜ企業は github や gitee ではなく gitlab を使用するのでしょうか?次の記事ではその理由と Gitlab のワークフローについて説明しますので、皆様のお役に立てれば幸いです。
公式の言い伝え:
GitLab は、 ネットワーク に基づいた MIT ライセンス を使用して GitLabInc. によって開発された Git ウェアハウス 管理ツールであり、## があります。 #wiki と問題追跡機能。コード管理ツールとして Git を使用し、これをベースにして Web サービスを構築します。
GitLab は、ウクライナのプログラマー Dmitriy Zaporozhets と Valery Sizov によって開発され、GitLab には Github と同様の機能があり、ソース コードを参照したり、欠陥やコメントを管理したりすることができます。リポジトリへのチーム アクセスを管理し、コミットされたバージョンの参照を容易にし、ファイル履歴ライブラリを提供します。チームメンバーは、内蔵の簡易チャットプログラム（ウォール）を使用してコミュニケーションできます。コードの再利用を容易にするコードスニペット収集機能も提供します。Ruby 言語で書かれています。その後、一部の部分を Go 言語 で書き直しました。 2018 年 5 月の時点で、同社には約 290 人のチーム メンバーと 2,000 人を超えるオープンソース貢献者がいます。 GitLab は、IBM、Sony、Jülich Research Center、NASA、Alibaba、Invincea、O’Reilly Media、Leibniz-Rechenzentrum (LRZ)、CERN、SpaceX などの組織で使用されています。
なぜ
なぜ企業は github や gitee ではなく gitlab を使用するのでしょうか? プロジェクトのバージョンが増え、開発者が増えると、単純な Git 管理では依然として多くの問題が発生します。一方で、開発者には過大な権限があり、他方では、運用および保守担当者の権限が不足します。私たちの開発プロセスをよく理解していないため、より良いツールを使用してプロジェクトを管理することを考えています。そこで私はgitlabを思いつきました。CI/CD
ここでの CI/CD は、実際には継続的インテグレーション (CI)、継続的デリバリー、継続的デプロイメント (CD) を指します。CI はソフトウェア エンジニアが行うものです。毎日更新されたコードのコピーを共有の場所に頻繁に配信するプロセス。すべての開発作業はスケジュールされた時間またはイベントに統合され、テストとビルド作業が自動化されます。 CI を使用すると、開発プロセス中に発生したエラーを適時に発見できるため、開発サイクル全体が短縮されるだけでなく、ソフトウェア エンジニアの作業がより効率的になります。 CD は継続的デリバリー (CD) の略で、高品質のアプリケーションを作成するためのパズルの 2 番目のピースです。 CD は、テクノロジとツールを使用して実稼働段階のコードを迅速に提供するソフトウェア開発分野です。配送サイクルの多くが自動化されているため、これらの配送は迅速に完了できます。 CI/CD ワークフローについては後ほど詳しく紹介します権限制御とコラボレーション
GitLab プロジェクトで共同作業する最も簡単な方法方法は、共同作業者に Git リポジトリへの直接プッシュ権限を与えることです。プロジェクト設定の「メンバー」セクションからプロジェクトにライターを追加し、新しいコラボレータをアクセス レベル (. コラボレータに「開発者」以上のアクセス レベルを与えることで、このユーザーはリポジトリに直接コミットできます)または制限なしで分岐します。コラボレーションをより分離するもう 1 つの方法は、マージ リクエストを使用することです。その利点は、プロジェクトを閲覧できるすべての共同作業者が、制御された方法でプロジェクトに貢献できることです。直接アクセスできるコラボレータは、ブランチを作成したり、このブランチにコミットしたり、マスターまたは他のブランチへのマージ リクエストを開くだけで済みます。リポジトリに対するプッシュ権限を持たない共同作業者は、リポジトリを「フォーク」し、 コピーにコミットして、そのコピーからメイン プロジェクトへのマージ リクエストを開くことができます。このモデルにより、プロジェクト所有者は、リポジトリに対してどのようなコミットが行われるか、また未知の共同作業者からの貢献がいつ許可されるかを完全に制御できます。 (これは github に似ていますが、現在 github のプライベート ライブラリは有料です)
GitLab でのリクエストと問題のマージは、長年にわたる議論の主要な部分です。各マージ リクエストでは、全体的なトピックだけでなく、変更が提案された行 (これにより軽量のコード レビューが可能になります) についてのディスカッションが可能になります。どちらもユーザーに割り当てることも、マイルストーン インターフェイスに編成することもできます。
このセクションでは主に GitLab の Git 関連機能に焦点を当てますが、成熟したシステムとして、GitLab はプロジェクト Wiki やシステム メンテナンス ツールなど、共同作業に役立つ他の多くの製品を提供します。 GitLab の優れた点の 1 つは、サーバーが起動して実行されると、構成ファイルを調整したり、サーバーに SSH 接続したりする必要がほとんどなくなり、ほとんどの管理と日常使用がブラウザ インターフェイス内で実行できることです。
Git Flow ワークフローの概要
一般的に、企業内のプロジェクトは複数の人によって同時に開発されるため、Git ブランチをどのように管理するかが重要な問題になります。 。
それでは、ここで git flow ワークフローを紹介する必要があります。
コードの実行環境から始めましょう。一般に、コードが実行される環境として、企業チームには少なくとも次の環境があります。
- ローカル開発環境: 開発者による自己テスト。ローカルにデプロイされた静的サーバーにすることもできます。もちろん、実行中の npm サーバーと同様の環境にすることもできます。ローカル環境で実行されるコードは、任意のブランチの
- dev 開発環境にすることができます。この環境は次のとおりです。開発に使用 唯一のパブリック
- テストおよびプレリリース環境は、開発ブランチ dev によって生成されたコードを使用してデプロイされます。この環境は、開発ブランチ リリースによって生成されたコードを使用してデプロイされ、唯一のパブリック環境です。
- オンライン運用環境: この環境は、開発ブランチ マスターによって生成されたコードを使用してデプロイされます。唯一のパブリック
対応する git ブランチ モデルは、
の対応するブランチ戦略です。
- release: 保護されたブランチ。開発されたすべてのブランチは、リリース ブランチにマージされ、テスト用にテスターに提供されます。
- feature-*: function ブランチ、特定の関数開発
- dev /test-*: 開発ブランチとダーティ ブランチ。全員が共有する開発環境に対応します。上記のコードは、開発者がセルフテストを実行し、日常および非日常のデバッグに対処できるように、パブリック開発環境にデプロイされます
- hotfix-*: バグ緊急修復ブランチ。マスターに直接マージできます (リリースが複数の機能ブランチをマージする場合、テスト中に緊急修復が必要な buf を検出します。緊急修復テストが完了すると、マスターに直接マージされます。リリースにマージされてからリリースからマスターにマージされた場合、テスト中の関数はまだオンラインになる準備ができていない可能性があります。関数は直接起動されます)
- 要件ドキュメントを受け取り、レビュー後、各個人またはグループが機能開発に割り当てられます。関連する担当者が機能ブランチを確認します。
- 開発中は、ローカルでのテストに加えて、必要に応じて dev ブランチにマージされ、パブリック開発環境で独自のテストを行うことができます
- 関数の開発中に、マスターにマージされるホットフィックスが存在する可能性があり、コードがマージされるため、競合を防ぐためにマスターをマージすることが習慣になっています。
- セルフテストが完了したら、リリースへのマージを申請します。マージが成功したら、テスト環境にデプロイし、テスターにテストを行うよう通知します。
- テストに合格すると、リリース アプリケーションはマスターにマージされ、オンラインになる準備が整います
##テストが失敗した場合は、機能ブランチを変更した後に再度マージします
- ##オンラインで成功して安定したら、対応する機能ブランチを削除し、開発者が最新のマスター ブランチとマージします ##(学習ビデオの共有:
- 基本的なプログラミングのビデオ
)
以上がなぜ企業は gitlab を使用するのでしょうか?ワークフローはどのようなものですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。