2023年 春期 応用情報技術者試験 問8

バージョン管理ツールの運用

A社は、業務システムの開発を行う企業で、システムの新規開発のほか、リリース後のシステムの運用保守や機能追加の案件も請け負っている。A社では、ソースコードの管理のために、バージョン管理ツールを利用している。

バージョン管理ツールには、1人の開発者がファイルの編集を開始するときにロックを獲得し、他者による編集を禁止する方式（以下、ロック方式という）と、編集は複数の開発者が任意のタイミングで行い、編集完了後に他者による編集内容とマージする方式（以下、コピー・マージ方式という）がある。また、バージョン管理ツールには、ある時点以降のソースコードの変更内容の履歴を分岐させて管理する機能がある。以降、分岐元、及び分岐して管理される、変更内容の履歴をブランチと呼ぶ。

ロック方式では、編集開始時にロックを獲得し、他者による編集を禁止する。編集終了時には変更内容をリポジトリに反映し、ロックを解除する。ロック方式では、一つのファイルを同時に1人しか編集できないので、複数の開発者で開発する際に変更箇所の競合が発生しない一方、①開発者間で作業の待ちが発生してしまう場合がある。

A社では、規模の大きな改修に複数人で取り組むことも多いので、コピー・マージ方式のバージョン管理ツールを採用している。A社で採用しているバージョン管理ツールでは、開発者は、社内に設置されているバージョン管理ツールのサーバ（以下、サーバという）のリポジトリの複製を、開発者のPC上のローカル環境のリポジトリとして取り込んで開発作業を行う。編集時にソースコードに施した変更内容は、ローカル環境のリポジトリに反映される。ローカル環境のリポジトリに反映された変更内容は、編集完了時にサーバのリポジトリに反映される。サーバのリポジトリに反映された変更内容を、別の開発者が自分のローカル環境のリポジトリに取り込むことで、変更内容の開発者間での共有が可能となる。

コピー・マージ方式では、開発者間で作業の待ちが発生することはないが、他者の変更箇所と同一の箇所に変更を加えた場合には競合が発生する。その場合には、ソースコードの変更内容をサーバのリポジトリに反映させる際に、競合を解決する必要がある。競合の解決とは、同一箇所が変更されたソースコードについて、それぞれの変更内容を確認し、必要に応じてソースコードを修正することである。

A社で使うバージョン管理ツールの主な機能を表1に示す。

表1　A社で使うバージョン管理ツールの主な機能
コマンド説明
ブランチ作成あるブランチから分岐させて、新たなブランチを作成する。
プルサーバのリポジトリに反映された変更内容を、ローカル環境のリポジトリに反映させる。
コミットソースコードの変更内容を、ローカル環境のリポジトリに反映させる。
マージローカル環境において、あるブランチでの変更内容を、他のブランチに併合する。
プッシュローカル環境のリポジトリに反映された変更内容を、サーバのリポジトリに反映させる。
リバート指定したコミットで対象となった変更内容を打ち消す変更内容を生成し、ローカル環境のリポジトリにコミットして反映させる。
注記：A社では、ローカル環境での変更内容を、サーバのリポジトリに即時に反映させるために、コミット又はマージを行ったときに、併せてプッシュも行うことにしている。

【ブランチ運用ルール】

開発案件を担当するプロジェクトマネージャのM氏は、ブランチの運用ルールを決めてバージョン管理を行っている。取り扱うブランチの種類を表2に、ブランチの運用ルールを図1に、ブランチの樹形図を図2に示す。

表2　ブランチの種類
種類説明
mainシステムの運用環境にリリースする際に用いるソースコードを、永続的に管理するブランチ。
このブランチへの反映は、他のブランチからのマージによってだけ行われ、このブランチで管理するソースコードの直接の編集、コミットは行わない。
develop開発の主軸とするブランチ。開発した全てのソースコードの変更内容をマージした状態とする。
mainブランチと同じく、このブランチ上で管理するソースコードの直接の編集、コミットは行わない。
feature開発者が個々に用意するブランチ。担当の機能についての開発とテストが完了したら、変更内容をdevelopブランチにマージする。その後に不具合が検出された場合は、このブランチ上で確認・修正し、再度developブランチにマージする。
releaseリリース作業用に一時的に作成・利用するブランチ。developブランチから分岐させて作成し、このブランチのソースコードで動作確認を行う。不具合が検出された場合には、このブランチ上で修正を行う。

・開発案件開始時に、mainブランチからdevelopブランチを作成し、サーバのリポジトリに反映させる。

・開発者は、サーバのリポジトリの複製をローカル環境に取り込み、ローカル環境でdevelopブランチからfeatureブランチを作成する。ブランチ名は任意である。

・featureブランチで機能の開発が終了したら、開発者自身がローカル環境でテストを実施する。

・開発したプログラムについてレビューを実施し、問題がなければfeatureブランチの変更内容をローカル環境のdevelopブランチにマージしてサーバのリポジトリにプッシュする。

・レビューでdevelopブランチのソースコードでテストを実施する。問題が検出されたら、ローカル環境のfeatureブランチで修正し、変更内容をdevelopブランチに再度マージしてサーバのリポジトリにプッシュする。テスト完了後、featureブランチは削除する。

・開発案件に関する全てのfeatureブランチがサーバのリポジトリのdevelopブランチにマージされ、テストが完了したら、サーバのdevelopブランチをローカル環境にプルしてからreleaseブランチを作成し、テストを実施する。検出された問題の修正はreleaseブランチで行う。テストが完了したら、変更内容をaブランチとbブランチにマージし、サーバのリポジトリにプッシュして、releaseブランチは削除する。

図1　ブランチの運用ルール
図2　ブランチの樹形図

【開発案件と開発の流れ】

A社が請け負ったある開発案件では、A，B，Cの三つの機能を既存のリリース済のシステムに追加することになった。

A，B，Cの三つの追加機能の開発を開始するに当たり、開発者2名がアサインされた。機能AとCはI氏が、機能BはK氏が開発を担当する。開発の流れを図3に示す。

図3　開発の流れ

I氏は、機能Aの開発のために、ローカル環境でaブランチからfeature-Aブランチを作成し開発を開始した。I氏は、機能Aについて（ア），（ウ），（オ）の3回のコミットを行ったところで、（ウ）でコミットした変更内容では問題があることに気が付いた。そこでI氏は、（α）のタイミングで、②（ア）のコミットの直後の状態に戻りたく戻すための作業を行い、編集をやり直すことにした。プログラムに必要な修正を加えた上でcした後、③テストを実施し、問題がないことを確認した。その後、レビューを実施し、aブランチにマージした。

機能Bは機能Aと同時に開発を開始したが、規模が大きく、開発の完了は機能A，Cの開発完了後になった。K氏は、機能Bについてのテストとレビューの後、ローカル環境上のaブランチにマージし、サーバのリポジトリにプッシュしようとしたところ、競合が発生した。サーバのリポジトリからaブランチをプルし、その内容を確認して競合を解決した。その後、ローカル環境上のaブランチを、サーバのリポジトリにプッシュしてからテストを実施し、問題がないことを確認した。

全ての変更内容をdevelopブランチに反映後、releaseブランチをdevelopブランチから作成して④テストを実施した。テストで検出された不具合を修正し、releaseブランチにコミットした後、再度テストを実施し、問題がないことを確認した。修正内容をaブランチとbブランチにマージし、bブランチの内容でシステムの運用環境を更新した。

【運用ルールについての考察】

feature-Bブランチのように、ブランチ作成からマージまでが長いと、サーバのリポジトリ上のdevelopブランチとの差が広がり、競合が発生しやすくなる。そこで、レビュー完了後のマージで競合が発生しにくくするために、随時、サーバのリポジトリからdevelopブランチをプルした上で、⑤ある操作を行うことを運用ルールに追加した。

出典：令和5年度 春期 応用情報技術者試験 午後 問8