2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
アプリ開発を効率化するCI/CD活用 - C#編(全1記事)
リンクをコピー
記事をブックマーク
松村優大氏(以下、松村):ここからは私、松村がお話をします。みなさん、本日はお集まりいただきましてありがとうございます。私は「アプリ開発を効率化する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#にフォーカスをして、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キーやパスワード、接続文字列など外部に流出すると困る情報ですね。そういったものの安全性が考慮されているかなど、クラウドにデプロイするアプリケーションの中だけでも特別に考慮すべきポイントが出てきます。
ドキュメントベースでこういったものを勉強するのは非常に大事ですが、弊社は先ほどのポイントをカバーできるKOSMISCHというサービスがあります。どういう製品かというと、C#の既存のアプリケーションをあらゆる観点から解析して、クラウドネイティブ化への道筋を示すアセスメントツールです。
KOSMISCHは、クラウドで動かすアプリケーションに対してやっておくべきことや、どういうインフラ構成をしたらいいかなどをアセスメントします。その結果をユーザーに見せて、開発に役立ててもらうというものです。
これはすでにあるアプリケーションにも、これから作るものにも適用できます。何らかの課題に対して、KOSMISCHがその課題をどうやって解決するかという方法を提示します。そのレポートをもとに、実際に開発者やチームで改善をしていく。そうすることで、最終的にはクラウドで実行させるための適したアプリケーションのかたちにできます。
アセスメントの機能はKOSMISCH Monolithというものです。KOSMISCH Monolithでは、今画面に映しているステートやミドルウェアや、C#そのもののコード、ほかにも既存のシステム向けですが、.NET Frameworkから.NET Coreへマイグレーションするための観点など、こちら(スライド)に載せているポイントでアセスメントのレポートを作成します。
その観点ですが、やはりスケーラビリティが非常に大きいです。これはクラウドを使う良さでもありますね。1台のサーバですべてを賄うのではなく、例えば処理の負荷に応じてサーバーの台数を増やすことが容易にできるのがクラウドを使う良さです。これは仮想マシンであろうと、いわゆるPaaSと言われる環境だろうと、同じような仕組みです。
ただ、スケールアウトをしたあとに適切に動かすためには、データの扱い方が非常に重要です。データベースのデータやキャッシュやログなどをサーバーの中で保管してしまうと、台数が増えたときに不整合が生じるので、データベースやキャッシュのサーバーなど外部のデータストアに保管しておく。ステートフルからステートレスにしたほうがいいですね。
KOSMISCHはGitで管理しているソースコードであれば、解析を行うことができますし、どの環境へデプロイするかはAzureとAWSの2つのクラウドで現在対応しています。
今回はレビューの観点で使い方を紹介しましたが、開発の前段階や、開発が終わったあとの運用フェーズでコードを継続的に改善していく段階になったときもアセスメントレポートを活用してもらえると我々は思っています。
アセスメントレポートの一例で、データベースですね。これは非常に簡単な結果にしていますが、例えばローカルホストですね。自分のサーバーの中のデータベースに接続している場合、スケールしたときにここで不整合が起きる可能性があるので、SQLデータベースのようなクラウドの別のデータベースサービスをきちんと使いましょうという案です。
ほかにも、スケーラビリティが考慮されているC#のコードかという観点もあります。簡単に言うとファイルやフォルダですね。これらの扱い方はクラウドでけっこう注意が必要です。あとは時間の考え方やタイムスタンプの考え方ですね。このようなアセスメントレポートを出しているので、興味があればまずはフリーアカウントで一度試してくれるとありがたいなと思います。
ぜひKOSMISCHでクラウドネイティブアーキテクチャへの不安を取り除いてもらいたいと思います。私からは以上です。ご清聴ありがとうございました。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには