前編では、ソフトウェア開発で避けることのできない不具合対応やトラブル対応において、ソースコードの作業履歴に残されている情報が問題解決に重要な役割を果たすことを説明しました。当たり前のことを述べたに過ぎませんが、肝心なのはその“残し方”です。
より良いコミットログを残すための工夫
良いコミットログを書くには、日ごろからの訓練が大切です。BitbucketやGitHubでホストされているオープンソースソフトウェアや、うまくいっているチームのコミットログを見て真似をしてみましょう。長文のコミットログを目にすることもあるはずです。日ごろのプルリクエストのコードレビューでも、コミットログにも注意を払うように心がけてください。さらに、適切なJIRAの課題キーが書かれているかどうかをチェックするしくみの導入も検討しましょう。Gitではコミットフックをカスタマイズし、コミットログが指定した書式のとおりに書かれているかどうかをチェックしてコミットを拒否することもできます。興味のある方はhttps://www.atlassian.com/git/tutorials/git-hooks/を参考にしてみてください。
集中型リポジトリであるSubversionの時代であれば、コミットのフックはサーバ1個所で実行すればよく、導入も比較的容易だったのですが、分散型リポジトリのGitでは開発者自らがローカルリポジトリを持つため、コミット時のチェックを導入するのはハードルが高いというジレンマもあります。また、自分でスクリプトを書くのがたいへんという方もいらっしゃるでしょう。こういった場合は、Bitbucket Serverにアドオンを導入して、プッシュやマージでチェックを実行するというしくみを検討してはいかがでしょうか。Atlassian Marketplaceで公開されている「Jira Hooks for Bitbucket」というアドオンを使えば、プッシュやマージのタイミングでのJIRAのチケットのチェックが可能です。ステータスがルールどおりでないときは、プッシュやマージを拒否することもできます。ただし、このアドオンは無償で提供されているため、ベンダからのサポートは受けられないことにご注意ください。
コード修正とリリース
ソースコードの修正が必要になった場合は、前回の記事で紹介したBitbucket ServerとSourceTreeの使い方を参考にしながらブランチを作成し、コードをコミット、プッシュして、プルリクエストでコードレビューを実施し、マージします。
不具合修正の場合は、bugfixブランチを作成して作業することになるでしょう。Bitbucket Serverはリポジトリごとにブランチモデルをカスタマイズでき、さまざまなブランチモデルに柔軟に対応します。git-flowブランチモデルなど、チームやプロジェクトに最適なブランチモデルを適用してください。ちなみに筆者らは自社製品のJIRAアドオンを開発してAtlassian Marketplaceに公開していますが、masterを開発用ブランチとして使うシンプルなブランチモデルを採用しています。
コードの修正後は、ビルドとテスト、リリースを行います。アトラシアン社のCIサーバであるBamboo(図1)を使えば、ビルドの自動化から配備の自動化まで、ソフトウェア開発に関わるさまざまなタスクを自動化できます。BambooはBitbucket Serverでブランチが作られたことを自動的に検知してビルドを走らせるため、プルリクエストでマージされる前の成果物をレビュー承認前にテストしたり検証環境へ配備して動作を確認したりといったことができます。開発のインフラをアトラシアン社のツールチェインでそろえることにより、課題管理、バージョン管理、ビルド、配備といったシステム連携がスムーズになります。
終わりに
サービスやプロダクトが成長していく中で、ソースコードの変更は避けられません。次回は、品質を保ちながらコードを改善していくコツや技術的負債の賢い返済方法について説明する予定です。
日本だけでなく、アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトのWebサイトでは、各アトラシアン製品の体験版を提供しているほか、アトラシアン製品専用のコミュニティも運営しています。まずはアクセスしてみては!
- リックソフトJIRAデモ環境
- https://www.ricksoft.jp/demo/