ソース管理とバージョン管理を調べる
ソースとバージョン管理の使用は、DevOps の基本的なプラクティスです。 また、継続的インテグレーションやコードとしてのインフラストラクチャなどのプラクティスの前提条件でもあります。どちらも、DevOps の可能性を最大限に引き出すために不可欠です。 サンプル シナリオの組織は、現在の共同ソフトウェア開発戦略を確認し、Git などの分散バージョン管理モデルに移行する必要があります。特に、ソフトウェア ライフサイクル管理に GitHub を使用する計画を検討してください。 ただし、これにはバージョンとソース管理の原則とその利点を健全に理解する必要があります。ここでは説明します。
ソース管理とバージョン管理
ソース管理とバージョン管理という用語は、多くの場合、同じように使用され、多くのコンテキストでは同じ概念を指します。 一般に、どちらも共有開発環境でコードに対する変更を管理する方法に関連付けられています。 ただし、意味が若干異なる、より微妙なシナリオが発生する場合があります。 これらのシナリオでは、ソース管理 、ソース コード ファイルへの変更を管理するシステムを指定します。一方、バージョン管理 には、ソース コード以外にも拡張する目的で、任意の種類のファイルの変更管理が含まれます。 今後、一貫性のために、バージョン管理 という用語を使用して、GitHub と Azure DevOps で使用可能な Git ベースのコラボレーション ソフトウェア リポジトリを表します。
バージョン管理の利点は何ですか?
バージョン管理では、管理の範囲内でファイルに対する変更を追跡します。 これには、次のようなさまざまな利点があります。
履歴とバージョンの追跡: 個々の変更がいつ行われたか、その範囲を特定する機能など、ファイルの変更履歴を確認できます。 これにより、一般的に各変更セットを一意の識別子に関連付けることで、追跡可能性も提供されます。
ロールバックと回復: エラーまたは問題がある場合は、変更を簡単に元に戻して、影響を受けるファイルの既知の動作バージョンを回復できます。
分岐とマージ: 別の機能を追加して現在のコードの機能を拡張する必要がある場合、または新しく検出されたバグを修正する必要がある場合は、いわゆるブランチを作成できます。これにより、既存のコードベースに対して独立して作業できます。 新しいブランチは、最初は現在のコードをホストしている メイン ブランチと同じです。 変更が完了したら、新しいブランチをメイン ブランチとマージします。 競合が引き続き発生する可能性はありますが (別の開発者が別のブランチ経由で同じファイル セットを変更することを決定した場合)、スコープは制限され、通常は簡単に識別して解決できます。
コラボレーションと並列開発: 分岐とマージによって補完される競合解決のプロビジョニングにより、複数の開発者が同じコードベースで作業することが容易になり、効率が向上します。 Git などの分散制御システムでは、切断モードでコードを作成することもできます。 コラボレーションには、プル要求の相互ピア レビューも含まれており、知識の共有と透明性が促進されます。
自動化: バージョン管理は、継続的インテグレーションと自動デプロイの重要な部分です。 コードの新しいバージョンがバージョン管理リポジトリにプッシュされるか、メイン ブランチとマージされるたびに、自動ビルドとテストを自動的にトリガーできます。 異なるバージョンのコードを異なる環境にデプロイできます。