スクラムチーム(Scrum Team)の開発者(Developers)は、インクリメント(Increment)を開発します。開発者がスプリントごとに作成するものがインクリメントです。スプリントごとに、前のスプリントで作成したものに追加していくことから「インクリメント=増分」と呼ぶのですね。

Scrum.orgスクラムガイドによると、開発者について次のように書かれています。

各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。

https://www.scrum.org/resources/scrum-guide

このシンプルな説明文の1行だけでも、かなり重要なポイントがあります。

スクラムがなんとなくうまくいかない時や、スクラム・アジャイルに対する誤解が大きい時には、この部分のイメージがうまくできていないのかもしれません。

続きを読む

例えばシナリオとして、「ドキュメントは Markdown 形式のテキストファイル(.md)で編集し、最終的な成果物として Word ファイルを作成する」というような場合、私は Pandoc を使用します。

ローカル環境なら、Pandoc をインストールして、Visual Studio Code の拡張機能も入れて・・・ これはこれで書式などを細かく調整するときには小回りが利いていいのですが、ドキュメントを書くメンバー全員がこれをやる必要はないなと感じてしまいます。

もしビルドパイプラインで Pandoc が使えるなら「Git リポジトリを更新すると、最新の Word ファイルが誰でもダウンロードできるようになっている!」ということが実現できます。

例えばシナリオとして、「GitHub のソースコードをビルドして、GitHub の Releases にリリースするときに、バージョン番号をファイルから取得してタグやタイトルに使用したい」というような場合を考えます。

GitHubRelease タスクには Tag や Release title が指定できるので「ver.$(version)」のように指定して「ver.1.0.2.3」のように展開されると嬉しいです。リリースノートは Release notes file path で指定できるので、Markdownファイルに書いておいてそのパスを指定することができますが、タグとタイトルはファイルのテキストそのままではなく、他の文字と連結したテキストにしたいところです。

現在ではクラウドの Azure DevOps を使用できれば、簡単にCI/CDを構成できます。開発者がコードを変更したら、自動的にビルドして、テストを行い、開発・動作確認用のWebサーバーなどに自動的にデプロイ。管理者に承認依頼が送信されて、承認すると、次のテスト環境や運用環境に自動でデプロイされる、という構成を簡単に作ることができます。

※CI/CD : Continuous Integration(継続的インテグレーション)/ Continuous Delivery(継続的デリバリー)

現代の開発では、このCI/CDなしにはもはや開発をすることができないと言っても過言ではありません。たとえクラウドのAzure DevOpsを使えなくても、常にCI/CDを実現したいものです。今回は、Azure DevOps Server(オンプレミス版の Azure DevOps、旧称 Team Foundation Server : TFS )を使用してこれを実現しました。

今回はこのフローを実現しました。ソースコードを変更すると自動的にWebサーバーに配置されます。