アプリケーション開発の効率化にはCI/CD設計が有効
松村優大氏（以下、松村）：ここからは私、松村がお話をします。みなさん、本日はお集まりいただきましてありがとうございます。私は「アプリ開発を効率化するCI/CD活用の仕方」についてお話ししたいと思います。今回はC#で作るアプリケーションでどうやるかお話をしたいと思います。
まずは私、松村はChief Technical Architectというポジションで活動しています。一番得意なのは開発系ですね。C#やPHP、Azureなどクラウドを使った開発を得意としています。このセッションの後半で、弊社の製品であるKOSMISCHを紹介します。
そのKOSMISCHの開発リーダーも務めています。Development Technologiesという領域でMicrosoft MVPも受賞しています。
このあとお話をするのは、アプリケーション開発を行う中で登場する、いろいろな定形作業ですね。そういったものを効率化するために、活用するCI/CDについてお話しします。CI/CDそのものの説明は、省略しますが、今日参加している未来のアーキテクトのみなさんが、クラウドのインフラ的なアーキテクチャ設計をやっていく中で、CI/CDと言われるパイプラインの設計も一緒にやっておくと非常に効果的だと思います。ですので、今回はC#を例にお話ししますが、JavaやPHPやPythonなど他の言語にもだいたい適用できると思います。
アプリケーションの品質保持のために自動化や仕組み化をする
アプリケーションを開発する工程は、要件定義から始まって、設計して開発して、テストを行って最終的にリリースするというのが一般的かなと思います。ウォーターフォールであれば、左から順にステップしていくし、アジャイル開発であれば、サイクルをどんどん短くするスプリントでやっていくということがいろいろな現場で行われていると思います。
この中で、CI/CDの仕組みがどこに当てはまるかというと、今矢印で映している範囲です。CIは、「継続的インテグレーション」の略です。開発やテストで行われる定型作業を仕組み化するのがCIです。2つ目のCDは、「継続的デリバリー」で、これは最後のリリース作業に大きく関わっています。
みなさんの環境やチーム、組織でCI/CDはすでに構築していたり、検討していたりすると思いますが、なぜCI/CDをここで作るべきか、私なりの考えはこちらです。
アプリケーションの品質を保ち続けるためですね。そのためにCI/CDを組むことが望ましいと思っています。一言で品質と言うとフワッとしていますが、開発そのものや開発全体のライフサイクルをどんどん加速したり、自動化されたビルドやリリースのプロセスを一貫して行ったりするための仕組み。そういったことをすることで、アプリケーションを安定的に動かすのも実現できます。
仕組み化することで、ビルドできないとか、何かテストで不具合が見つかったとか、ソースコードやアプリケーションが不健全な状態な場合、公開しないように途中で止めることもできます。そういった作業を人ではなく、ツールにさせることで、開発者は開発にもっと集中できます。
関わる人たちが、自分の本来の作業に集中できるようになるのが、CI/CDを使うことの良さだと私は考えています。
そのCI/CDですが、今はいろいろなツールが世の中にありますね。みなさんが使っているものが、この中にも載っているかもしれません。Azure DevOpsやGitHub ActionsやJenkinsやCircleCIなど。他にもたくさんあるので、自分のチームに適したものをぜひ選定してみてください。ちなみにオルターブースでは、左上のAzure DevOpsをよく使っています。
CI/CDを導入するまであと一歩というケースもあるかなと思います。例えば、ソースコードのバージョン管理がまだできていないとか、ビルドをするために、あらかじめパソコンやサーバに何かインストールをしておかなければいけないなど、特別な環境が必要な工程があるとか。
ほかにも、アプリが使っている言語やフレームワークのコマンドラインが提供されていないとかですね。こういったケースだと、先ほどお見せしたツールを使って一気に自動化は若干難しいかもしれません。特に3番目のコマンドラインが非常に大事で、基本的にはスクリプトを書くので、コマンドラインでいろいろな作業ができるということが前提になります。
C#言語フレームワークの.NET Frameworkと.NET Core
次に今日のC#にフォーカスをして、CI/CDをC#でどうやるかをお話ししますが、C#という言語は、現状2つのフレームワークが提供されています。.NET Frameworkと、.NET Coreの2つです。それぞれできることが違います。
後発の.NET Coreが作れるアプリケーションの種類がだんだんと増えてきています。コンソールのアプリケーションやデスクトップクライアントなアプリ、Webのアプリケーションも2つのフレームワークで作れます。個人的には、使うフレームワークは.NET Coreに一本化するのがいいと思います。
その理由は、バージョンの問題や実行できる環境ですね。あとはコマンドラインの違いがあります。.NET Coreの場合、WindowsだけではなくmacOSやLinuxの環境でも動かすことができます。ほかにもバージョンですね。.NET Frameworkは4.8が最新ですが、今後メジャーアップデートが行われないというアナウンスがすでに出ています。
対して.NET Coreは、現状3.1のLTSに加えて.NET 5が出ており、つい最近、.NET 6のPreview 1のアナウンスが出ています。進化が早いフレームワークです。
大きな違いはコマンドラインです。CI/CDでやるビルドやデプロイですね。.NET Frameworkでも、MSBuildやMSDeployというツールを使うことで実現できますが、もっとカバーを広げていくと、.NET Core CLIが使える.NET Coreのほうがよりよい構築ができると思います。
その.NET Core CLIの一部をこの表に載せています。CI/CDでよく使うのが、今オレンジ色で網掛けをしているrestoreとbuild、testやpack、publishといったコマンドですね。これらはCI/CDの工程の中で書いていきます。CLIをすべて一本化するdotnetコマンドで、集約されるのですごく扱いやすいです。
オルターブースが使っているAzure DevOpsは、5つの大きな機能に分かれていて、CI/CDをやるには、Azure Pipelinesという機能を使って自動化の仕組みを作っていきます。この機能を使うと、開発者が開発に集中できる環境が作れます。
自分の作業に集中できるということですね。自動化できるものは自動化できる仕組みになっています。これはマイクロソフトの公式ドキュメントに載っている一例です。開発者がソースコードをコミットして、プッシュするところを起点として、Azure Pipelinesを使ってビルドをしてそれをAzureにデプロイして、いろいろなテレメトリをクラウド上で見る。この（1）番の作業にまず集中できるというのが大きな利点です。
Azure Pipelinesの場合、作り方がいくつかあります。以前はGUIで、ブロックみたいな形式でCI/CDの流れを作っていましたが、今はClassicという表記に変わっていて、いずれ終了する可能性もあります。なので、現在の主流はYAMLファイルにパイプライン定義を記述して、それを使って自動化の処理を行うというものです。
載せているYAMLファイルは、非常にシンプルに書いた.NETのアプリケーションのビルドやテスト、パッケージングのコードです。これ自体はさほど難しくないです。DevOps上でもクリック操作で作ることができるので、まずはこういうかたちでやってみて、そこから必要な機能の処理を足したり拡張したりするといいと思います。
アプリケーション品質の担保に必要なレビュー
ここまではCI/CDの話をしましたが、構築したからといってアプリケーションの品質が保てるわけでは、やはりないですね。CI/CDがすべての品質を担保してくれるわけではないです。作る、開発をする、設計をする、これらの人たちがどうやって改善していくかがポイントです。
その中の1つの作業として、レビューを私は重要視しています。レビューは他の人に内容を見てもらうということですね。「設計をしたのでレビューをしてください」とか、「コードを書いたのでレビューをしてください」とか、いろいろな段階でレビューのステップが出てくると思います。リリースの直前にきちんと品質のチェックをするというレビューもですね。いろいろなステップでレビューの工程が出てきます。
今回のようなクラウドを使ったシステム、アプリケーションを作るときは、クラウド特有のレビューの観点が出てきます。これは慣れるまでは非常に難しいと思います。まず、いったいどういうものがあるのか慣れるまでに時間がかかると思います。例えば、スケーラビリティが考慮されている設計やコードになっているか。あとは稼働時間などの非機能要件がカバーされているかどうか。
ほかにも、クラウドを使ったSDKやAPIが適切に使われているかですね。あとはシークレットと言われるAPIキーやパスワード、接続文字列など外部に流出すると困る情報ですね。そういったものの安全性が考慮されているかなど、クラウドにデプロイするアプリケーションの中だけでも特別に考慮すべきポイントが出てきます。
あらゆる観点からC#アプリケーションをアセスメントするKOSMISCH
ドキュメントベースでこういったものを勉強するのは非常に大事ですが、弊社は先ほどのポイントをカバーできるKOSMISCHというサービスがあります。どういう製品かというと、C#の既存のアプリケーションをあらゆる観点から解析して、クラウドネイティブ化への道筋を示すアセスメントツールです。
KOSMISCHは、クラウドで動かすアプリケーションに対してやっておくべきことや、どういうインフラ構成をしたらいいかなどをアセスメントします。その結果をユーザーに見せて、開発に役立ててもらうというものです。
これはすでにあるアプリケーションにも、これから作るものにも適用できます。何らかの課題に対して、KOSMISCHがその課題をどうやって解決するかという方法を提示します。そのレポートをもとに、実際に開発者やチームで改善をしていく。そうすることで、最終的にはクラウドで実行させるための適したアプリケーションのかたちにできます。
アセスメントの機能はKOSMISCH Monolithというものです。KOSMISCH Monolithでは、今画面に映しているステートやミドルウェアや、C#そのもののコード、ほかにも既存のシステム向けですが、.NET Frameworkから.NET Coreへマイグレーションするための観点など、こちら（スライド）に載せているポイントでアセスメントのレポートを作成します。
その観点ですが、やはりスケーラビリティが非常に大きいです。これはクラウドを使う良さでもありますね。1台のサーバですべてを賄うのではなく、例えば処理の負荷に応じてサーバーの台数を増やすことが容易にできるのがクラウドを使う良さです。これは仮想マシンであろうと、いわゆるPaaSと言われる環境だろうと、同じような仕組みです。
ただ、スケールアウトをしたあとに適切に動かすためには、データの扱い方が非常に重要です。データベースのデータやキャッシュやログなどをサーバーの中で保管してしまうと、台数が増えたときに不整合が生じるので、データベースやキャッシュのサーバーなど外部のデータストアに保管しておく。ステートフルからステートレスにしたほうがいいですね。
KOSMISCHはGitで管理しているソースコードであれば、解析を行うことができますし、どの環境へデプロイするかはAzureとAWSの2つのクラウドで現在対応しています。
今回はレビューの観点で使い方を紹介しましたが、開発の前段階や、開発が終わったあとの運用フェーズでコードを継続的に改善していく段階になったときもアセスメントレポートを活用してもらえると我々は思っています。
アセスメントレポートの例
アセスメントレポートの一例で、データベースですね。これは非常に簡単な結果にしていますが、例えばローカルホストですね。自分のサーバーの中のデータベースに接続している場合、スケールしたときにここで不整合が起きる可能性があるので、SQLデータベースのようなクラウドの別のデータベースサービスをきちんと使いましょうという案です。
ほかにも、スケーラビリティが考慮されているC#のコードかという観点もあります。簡単に言うとファイルやフォルダですね。これらの扱い方はクラウドでけっこう注意が必要です。あとは時間の考え方やタイムスタンプの考え方ですね。このようなアセスメントレポートを出しているので、興味があればまずはフリーアカウントで一度試してくれるとありがたいなと思います。
ぜひKOSMISCHでクラウドネイティブアーキテクチャへの不安を取り除いてもらいたいと思います。私からは以上です。ご清聴ありがとうございました。
