データインサイダー

ソースコード管理とは?

ソースコード管理とは、ソースコードの変更を追跡管理することです。コードベースに対する変更履歴を保持することにより、プログラマー、開発者、テスターは常に最新の適切なコードで作業していることが保証されます。また、複数のソースからのコードをマージ(結合)する際に競合を解決することもできます。

ソースコード管理が重要なのは、開発環境では一般的に複数の開発者が1つのコードベースを共有するためです。この場合、各開発者が実装した担当機能のコードが競合する問題や、ある開発者が保存した内容を別の開発者が上書きする問題が起こり得ます。

ソースコード管理を導入しない限り、こうした問題を防止する策はほとんどありません。せいぜい、開発者が作業を始めるたびに、他の開発者全員にそれを知らせて、そのコードファイルを同時に編集しないよう注意を促すことくらいです。

それは確実なプロセスとはとても言えません。仮にうまくいったとしても、この方法ではプロジェクト内で行われたすべての変更の履歴を残すことができず、コード変更によってバグが発生した場合に、その原因となった箇所を突き止めて解決策を探ることはできません。

ソースコード管理は、各開発者が行った変更を記録し、競合を検出して、コードの上書きを防ぐことにより、これらの問題を解決します。競合が検出されたときは開発者に通知されるため、ソースコードにマージする前に修正して、アプリケーションでバグが発生するのを防止できます。

以下のセクションでは、ソースコード管理の仕組み、ソースコード管理がソフトウェア開発にもたらすメリット、ソースコード管理プロセスを最大限に活用するためのベストプラクティスについて説明します。

ソースコード管理とは:目次

ソースコード管理の仕組み

ソースコード管理プロセスの中核を担うのは、コードリポジトリとソースコード管理システムです。コードリポジトリは、組織のすべてのコードが保存される中央のサーバーで、ソースコード管理システムは、さまざまな開発プロジェクトのコード変更を追跡するシステムです。

ソースコードはそれぞれ、個別のファイルとして保存されます。開発者がコードのリビジョンを作成するためにファイルを「チェックアウト」すると、開発者のローカル環境にファイルのコピーが送信されます。このとき、リポジトリ内のオリジナルファイルがロックされるため、他の人がチェックアウトして、現在編集している開発者の変更内容を意図せず上書きするのを防ぐことができます。開発者は、コードを変更してテストした後、ファイルを「コミット」して、変更後のコードをリポジトリに保存します。これによって、変更されたファイルが新たなオリジナルファイルになり、「バージョン管理」と呼ばれるプロセスによってコードのバージョン番号が1つ上がり、ロックが解除されます。

他の開発者がどのファイルのコードを変更する場合でも、常に同じプロセスが繰り返されます。ソースコード管理システムは、すべてのリビジョンを保存および管理して、各コードの完全な履歴を保持します。

すべてのソースコード管理ツールで共通して使用される用語がいくつかあります。

  • リポジトリ(Gitリポジトリなど):プロジェクトで作成されたすべてのコードファイルが保存されるサーバー。コードの変更を追跡するソースコード管理システムでもあります。開発者は、コードファイルを「チェックアウト」して変更を行い、作業が完了したらファイルをリポジトリに戻します。このとき、元のファイルは上書きされず、変更後のファイルは新しいバージョンとして保存されます。
  • チェックアウト:リポジトリから開発者の作業環境にファイルを取り込むこと。このとき、他の開発者が変更できないようにファイルが自動的にロックされます。
  • チェックイン:チェックアウト後、変更が完了したファイルをリポジトリに戻して保存すること。これによりファイルのロックが解除されます。
  • コミット:「チェックイン」の別称。
  • トランク:バージョン管理されているファイルツリーの主流の開発ライン。
  • ブランチ:プロジェクトのトランクからコードのコピーを作成して分岐すること。ブランチを使うことで、同じファイルの複数のコピーを作成し、互いに影響しない状態で目的の異なる変更を加えることができます。
  • マージ:2系統の変更を1つのファイルに統合すること。たとえば、ブランチをトランクに統合することや、2つのブランチを統合することができます。マージには検討すべきさまざまな方法があります。たとえば、あるブランチのコミットを別のブランチに書き換えたいときは「リベース」を行います。

ソースコード管理のメリット

ソースコード管理にはさまざまなメリットがあります。

  • 完全なバージョン履歴の保持:ソースコード管理システムには保存されたすべてのコード変更の履歴が保持されるため、ファイル内で行われたすべての変更内容と、その変更者、変更理由を、プロジェクトの全期間にわたって確認できます。また、必要に応じてコード変更を以前のバージョンにロールバックすることもできます。
  • コラボレーションの効率化:複数の開発者が各自の作業環境で、他の人の変更内容を上書きすることなく、異なる範囲のコードを編集できます。複数の開発者によるコード変更で競合が発生した場合はアラートが通知されるため、内容を確認して適切に対処することにより、マージ後のコードにエラーが入り込むのを防ぐことができます。
  • ワークフローの自動化:ソースコード管理を効果的に行うには、定められたワークフローに従って開発作業を行う必要があります。ソースコード管理ツールによっては、コメントの有効化、特定のステップ完了時のメール通知、期日までに作業が完了しなかった場合のマネージャーへの報告など、一部の必須事項を自動化できます。
  • コミュニケーションの促進:ソースコード管理ツールでは通常、ワークフロー内の特定のコード変更についてコメントを残すことができます。これにより、開発チーム、マネージャー、ユーザー間のコミュニケーションを促進できます。この機能はチームメンバーが地理的に分散している場合は特に効果的です。
  • コード履歴のグラフィカル表示:ソースコード管理ツールによっては、コード履歴をダイアグラムで表示して、コードのブランチ、マージ、リリース状況を一目で確認できます。
  • リリースノートの自動生成:ソースコード管理システムでは、コードがリリースとリンクされ、リリースノートが自動的に生成されます。これにより、変更の検索や手動でのノート作成にかかる時間を節約できます。
  • コードのバックアップ:ソースコード管理システムでは、開発者がコードを保存するための一元的な場所が提供されます。この仕組みには、すべての開発者がコードにアクセスできるだけでなく、開発者が各自のPCにコードを保存する場合よりも簡単にコードをバックアップできるメリットがあります。 
  • パイプラインの分析:ソースコードを適切に管理すれば、パイプライン分析の効果を向上させることができます。アプリケーションレベルとインフラレベルのメトリクスを追跡することで、アプリケーション環境を詳細に可視化し、アプリケーションやインフラでのパフォーマンスの問題をすばやく特定して解消できます。

バージョン管理の役割

バージョン管理とは、コードの変更を時間に沿って追跡できるようにリビジョンを管理することです。ソースコード管理と同じ意味で使われることもよくあります。

バージョン管理に対応したソフトウェアでは、特殊なタイプのデータベースで、すべてのコード変更が追跡されます。開発者がファイルを変更して保存しても、そのファイルの以前のバージョンで行われた変更は上書きされず、履歴としてすべて保持されます。

このようにすべてのコード変更をバージョンで分けて維持することにはいくつかのメリットがあります。

  • ソースコードを保護できる:ソースコードを適切に管理して、誰かが誤って上書きしたり削除したりする事故を防ぐことができます。
  • 以前のバージョンとコードを比較し、必要に応じて復元できる:コードの完全な履歴があれば、現在のコードベースと以前のバージョンを比較して、ミスの修正に役立てることができます。変更によってバグが発生した場合や、複数の変更が競合する場合には、前のバージョンにロールバックすることもできます。
  • 複数の開発者が個別に作業できる:開発者は各自の作業環境で独自のコード変更を行い、完了後にそれぞれの変更をマージできます。変更で競合が発生した場合はアラートによって通知され、適切に対処することができます。

ブランチの扱いの違いによって、バージョン管理システムは集中型と分散型の2種類に分けられます。

  • 集中型のバージョン管理システム:中央のサーバーにプロジェクトのコピーが1つ保持され、コード変更はすべてこのサーバーに対してコミットされます。開発者は、作業するファイルをチェックアウトできますが、プロジェクト全体のコピーをローカルに取り込むことはできません。
  • 分散型のバージョン管理システム:開発者が各自のローカル環境に、プロジェクトの全履歴を含むリポジトリのクローンを作成できます。その後、このマスターリポジトリのローカルコピーから、作業するコードのクローンを作成します。作業が完了したら、ローカルのソースコードリポジトリに変更をコミットし、ローカルリポジトリのコードをマスターリポジトリに「プッシュ」します。

いずれのタイプのバージョン管理システムにもメリットとデメリットがあります。集中型は、分散型よりもセットアップが簡単で、構成もシンプルであり、使い方がわかりやすいというメリットがあります。また、コードが単一のサーバーに保存されるため、アクセス管理も容易です。分散型は、ネットワークに接続する必要がなく、ネットワークの遅延の影響を受けないため、一般的に集中型よりもパフォーマンスが高速です。また、コードベース全体がローカルにあるため、コードファイルのロック解除を待つ必要がありません。さらに、メインサーバーで障害が発生しても、分散型なら完全なコード履歴がローカルに保存されているため、それをバックアップとして使用できます。

ソースコード管理システムとは

ソースコード管理システムは、ソフトウェア開発チームのコーディング作業を調整するソフトウェアツールで、BitbucketやIBM Rational Clearcase、オープンソースではGithubやApache Subversionなどがあり、「バージョン管理システム」や「ソース管理システム」と呼ばれることもあります。

ソースコード管理システムの主な機能は、ファイル、設定、バージョンの管理です。これらの機能を使って、開発チームが常に最新のコードで作業していることを保証するとともに、開発者が互いのコード変更を上書きしてしまうのを防ぐことができます。ソースコード管理ツールを使用すれば、複数の開発者が並行してコーディングを行い、作業が完了したら変更をマージできます。また、要求された変更の追跡とレビュー、バグ修正の監視、リリース作業もツール内で実行できます。

市場にはさまざまなソースコード管理ツールまたはシステムが提供されています。ツールを選択するときは、組織の規模、リソース、ニーズに最適な機能の種類や範囲を検討します。

DevOpsライフサイクルにおけるソースコード管理の役割

ソースコード管理はDevOpsライフサイクルにおいて重要な役割を果たします。その役割を理解するには、ライフサイクル全体を把握する必要があります。最近のソースコード管理システムの多くは、CI/CD機能を備えています(Githubアクション、Gitlabパイプライン、Microsoft Azure DevOps Serverなど)。

DevOpsライフサイクルは、ソフトウェア開発プロジェクトの構造と継続性を確立する7つのフェーズで構成されます。各フェーズは次のとおりです。

  • 継続的開発:DevOpsライフサイクルの最初のフェーズは、計画とソフトウェアのコーディングです。このフェーズでは、プロジェクトのビジョンを確立し、アプリケーションの初期ソースコードを作成して管理します。
  • 継続的インテグレーション:このフェーズでは、ソースコードを日または週単位で継続的に改修するとともに、アプリケーションに新しい機能を追加するための新しいコードを記述してメインコードベースに統合します。記述したコードの単体テスト、コードレビュー、統合テスト、コンパイル、パッケージングの際にバグが見付かることもあります。
  • 継続的テスト:コードをテスターに送り、アプリケーションのパフォーマンスチェックとバグ検出のためのテストを実行します。テスト後、開発者は結果を受け取り、必要に応じてコード変更を行ってバグを修正し、アプリケーションのパフォーマンスを最適化します。
  • 継続的監視:このフェーズでは、アプリケーションとそのインフラのパフォーマンスと信頼性を監視します。その監視データに基づいて、アプリケーションサービスの可用性を判定し、システムエラーの根本原因やセキュリティの問題の特定と対応を行います。
  • 継続的フィードバック:顧客からフィードバックを収集して、アプリケーションのユーザーエクスペリエンスを評価します。フィードバックには、アンケート、市場調査、フォーカスグループなどによって収集する構造化データと、FacebookやTwitterなどのソーシャルメディアから収集する非構造化データがあります。開発者は、顧客からのフィードバックに基づいて現行のアプリケーションを評価し、ユーザーのニーズに合わせて変更を行います。
  • 継続的デプロイ:このフェーズでは、完成したアプリケーションコードを本番環境のサーバーにデプロイして、ユーザーが利用できるようにします。
  • 継続的運用:最後のフェーズでは、アプリケーションのリリースとアップデートのプロセスを自動化して、市場投入までの時間を短縮します。
DevOpsライフサイクル

ソースコード管理のベストプラクティス

以下のベストプラクティスに従えば、ソースコード管理を最大限に活用できます。

  • コミットを頻繁に行う:コミットすると、その時点でのコードベースのスナップショットを作成できます。コミットを頻繁に行えば、完了した変更をコードベースに逐一保存して、エラーが発生したときにより細かい単位で以前の状態に戻すことができます。
  • コミットメッセージを残す:コミットメッセージを使えば、変更に関する情報を他の開発者に伝えることができます。また、トラブルシューティングの際に、どの変更で問題が生じたかを特定するためにも役立ちます。コミットメッセージの書き方は開発チームによって異なりますが、一般的には、コミットのタイプ(新機能、バグ修正、リファクタリングなど)を簡潔に示した後、変更内容と変更理由の詳しい説明を記入します。パイプライン分析では、コミットメッセージにバックログチケット番号を含めます。 
  • 最新バージョンで作業していることを確認する:複数の開発者が頻繁にコードを更新している場合は、コードベースのローカルコピーがすぐにマスターコードベースよりも古くなってしまいます。変更を行うときは、事前にコードベースのバージョンをチェックして、常に最新バージョンで作業するように心掛けましょう。また、マイクロサービスとCI/CDパイプラインではバージョン管理が大きく異なることにも注意が必要です。 
  • チームのワークフローを標準化する:開発者にはそれぞれプロジェクトの進め方に好みがあります。しかし、ソースコード管理ツールとそのプロセスの効果を引き出すには、高品質の製品を生み出す基盤となる共通のワークフローを確立することが重要です。
  • ブランチを活用する:ブランチを使用すれば、個別の開発ラインを作成して、複数の開発者が同じコードベースで互いの作業に影響を与えることなく並行して作業できます。メインの開発ラインへの統合を円滑化するためのブランチの使用方法と戦略を定めた上で(変更を行うときは常に新しいブランチを作成するなど)、それらを守りながらブランチを積極的に活用しましょう。
ソースコード管理のベストプラクティス

結論:ソースコード管理は今日のソフトウェア開発の基本

ソフトウェア開発では、プロジェクトとそのコードベースの数や規模が拡大し複雑化するにつれて、ソースコード管理ツールの重要性が増します。修正するアプリケーションのバージョンを間違え、さらに悪い場合には修正すべきバグを残したままリリースしてしまうと、時間、コスト、顧客の信頼を大きく損なうことになります。ソースコード管理は簡単に導入でき、効果的に実践すれば、開発プロセスを加速させ、チームの生産性を向上させ、製品の品質を改善することができます。

参考リソース