応用情報技術者 2023年 春期 午後 問08

　A社は、業務システムの開発を行う企業で、システムの新規開発のほか、リリース後のシステムの運用保守や機能追加の案件も請け負っている。A社では、ソースコードの管理のために、バージョン管理ツールを利用している。 　バージョン管理ツールには、1人の開発者がファイルの編集を開始するときにロックを獲得し、他者による編集を禁止する方式（以下、ロック方式という）と、編集は複数の開発者が任意のタイミングで行い、編集終了後に他者による編集内容をマージする方式（以下、コピー・マージ方式という）がある。また、バージョン管理ツールには、ある時点以降のソースコードの変更内容の履歴を分岐させて管理する機能がある。以降、分岐元、及び分岐して管理された、変更内容の履歴をブランチと呼ぶ。 　ロック方式では、編集開始時にロックを獲得し、他者による編集を禁止する。編集終了時には変更内容をリポジトリに反映し、ロックを解除する。ロック方式では、一つのファイルを同時に1人しか編集できないので、複数の開発者で開発する際に変更箇所の競合が発生しない一方、①開発者間で作業の待ちが発生してしまう場合がある。 　A社では、規模の大きな改修を複数人で取り組むことも多いので、コピー・マージ方式のバージョン管理ツールを採用している。A社で採用しているバージョン管理ツールでは、開発者は、社内に設置されているバージョン管理ツールのサーバ（以下、サーバという）のリポジトリの複製を、開発者のPC上のローカル環境のリポジトリとして取り込んで開発作業を行う。編集時にソースコードに施した変更内容は、ローカル環境のリポジトリに反映される。ローカル環境のリポジトリに反映された変更内容は、編集完了時にサーバのリポジトリに反映させる。サーバのリポジトリに反映された変更内容を、別の開発者が自分のローカル環境のリポジトリに取り込むことで、変更内容の開発者間での共有が可能となる。 　コピー・マージ方式では、開発者間で作業の待ちが発生することはないが、他者の変更箇所に同一箇所に変更を加えた場合には競合が発生する。その場合には、ソースコードの変更内容をサーバのリポジトリに反映させる際に、競合を解決する必要がある。競合の解決とは、同一箇所が変更されたソースコードについて、それぞれの変更内容を確認し、必要に応じてソースコードを修正することである。 　A社で使うバージョン管理ツールの主な機能を表1に示す。

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

〔開発案件と開発の流れ〕 　A社が請け負ったある開発案件では、A、B、C の三つの機能を既存のリリース済のシステムに追加することになった。 　A, B, C の三つの追加機能の開発を開始するに当たり、開発者2名がアサインされた。機能 A と C は I 氏が、機能 B は K 氏が開発を担当する。開発の流れを図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 ブランチをプルした上で、⑤ある操作を行うことを運用ルールに追加した。