そろそろ、「入社してからずっとリモートワークで、他の人がプログラミングする様子を見たことがない！」という方も多いのではないでしょうか？私がプログラミングを始めたばかりのころは、他の人がコードを書いているのを後ろから見て、「あぁ、そうやってやるのか」と自然に覚えたことも沢山あったので、今からプログラミングを始める人は、もしかしたらそういう機会が少ないのではないか？とちょっと心配しています。
また、プログラミングが上達してくると、後輩から「それどうやってるんですか？早くて全然何やってるか？わかりません」と言われて、コードの書き方やIDEの使い方を教えたりという機会がありました。そういう機会も最近は少ないような気がします。こんな状況であっても先輩として、後輩にさっと覚えておいてほしいことを伝えられるようにと、今回 Visual Studio の便利な使い方の中で、特にプログラミングが劇的に早くなる方法を５つ選んでまとめました。
最近、プロジェクトで Azure DevOps を使うことが多くなってきて、「Azure DevOps の Board の正しい使い方を教えてください。」というようなことを、よく質問されるようになってきました。
Azure DevOps は簡単に使い始めることができるので、かえって、自分たちがちゃんと使えているのか不安に思うのかもしれません。Azure DevOps 自体は、自分たちのプロジェクトに合わせて、自由に変えてよいのですが、例えば Scrum.org ではアジャイルのフレームワーク「スクラム」を変えないように（変えてしまうと スクラム じゃないよ）というような事が示されていたと思います。自分たちの好きにかえて、正しくない使い方をしてしまうのは不安。正しく使いたい。という気持ちはよくわかります。
なので、今回は「スクラムとしてAzure DevOpsを使用するにはどうするのがよさそうか」という観点で見てみたいと思います。Azure DevOps にはすでに Scrum テンプレートが設定されているものとします。
例えばシナリオとして、「ドキュメントは 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ファイルに書いておいてそのパスを指定することができますが、タグとタイトルはファイルのテキストそのままではなく、他の文字と連結したテキストにしたいところです。
スクラムのチームは全員が同じ場所にいることが推奨（だったと思います、Scrum.org の Scrum Guide には書いてないかも）ですが、そうも言っていられない状況。しかし、リモートワークでスクラムをする場合には、かなり頑張って、メンバーが密にコミュニケーションできるように準備する必要があります。
そのための工夫のひとつとして Azure DevOps のタスクのメンションを使うのが良い感じです。
スクラムイベントの スプリント振り返り ( Sprint Retrospective ) は Scrum.org の Scrum Guide に定義されています。スプリント期間の終了時に、スプリント期間1週間につき 45分（4週間なら3時間）の時間をとって、何が良かったか？何が良くなくてどう改善するか？をみんなで話し合います。
他のスクラムイベントはしっかりやれているのに、スプリント振り返り だけやれてないという話はよく聞きます。重要なこのイベントを、ちゃんとやれるように何とか定着させたいところです。
スクラムイベントは Scrum.org の Scrum Guide に定義されています。
新しく開発チームのサイトを作るときに、サイトの Welcomeページにこれらのイベントを記載してメンバーに周知したいので、私はよく README.md 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サーバーに配置されます。
デフォルトでは有効になっていないオプションなので、知っている人は使っているケド、知らない人は知らない機能。
Visual Studioで、ソースコードなどのウィンドウを選択してアクティブにしたら、ソリューションエクスプローラーでも同じファイルを選択するようにすることができます。
前回の話 では、変数の生存期間をできるだけ短くする話をしましたが、今回はメソッドの話です。同じリファクタリングのなかで指摘したお話です。
