Skip to content

#90DaysOfDevOps - アプリケーションフォーカス - 3日目

DevOps ライフサイクル - アプリケーションフォーカス

もしあなたがDevOpsエンジニアの役割を目指しているのであれば、繰り返し行うことに慣れるでしょうが、毎回常に向上させることは、物事を面白く保つもう1つのポイントです。

この時間では、アプリケーションの開始から終了までのハイレベルなビューを見て、一定のループのように戻ってくることにします。

開発

開発者として、クライアントやエンドユーザーと要件について話し合い、アプリケーションのためのある種の計画や要件を考え出さなければならないかもしれません。次に、要件から新しいアプリケーションを作成する必要があります。

この段階では、IDEとアプリケーションを書くのに使いたいプログラミング言語を選択する以外には、ツールに関する本当の要件はありません。

DevOpsエンジニアとして、あなたはおそらくこの計画を作成したり、エンド・ユーザーのためにアプリケーションをコーディングしたりする人ではないことを忘れないでください。

しかし、アプリケーションのために前進する最適なインフラストラクチャの決定を行うことができるように、コードの一部を読むことができても問題ないでしょう。

このアプリケーションはどのような言語でも書けることは前述しました。重要なのは、バージョン管理システムを使って保守することです。これは後ほど詳しく説明し、特に Git について掘り下げます。

また、このプロジェクトに取り組む開発者は一人ではないと思われますが、それでもベストプラクティスでは、コードを保存して共同作業するためのコードリポジトリが必要です。これはプライベートでもパブリックでもよく、ホスティングでもプライベートでも展開できます。後ほど、Gitのセクションの一部として、これらもカバーします。

テスト

この段階で、私たちは要件を満たし、アプリケーションを開発することができます。しかし、私たちは、私たちが利用可能なすべての様々な異なる環境、または特に選択したプログラミング言語で私たちのコードをテストしていることを確認する必要があります。

このフェーズでは、QAがバグをテストすることができます。テスト環境のシミュレーションにコンテナが使用されることが多くなり、物理インフラやクラウドインフラのコスト・オーバーヘッドを全体的に改善することができます。

このフェーズは、次の継続的インテグレーション（Continuous Integration）の一部として自動化される可能性も高い。

QAエンジニアが数十人、数百人、あるいは千人単位で手作業でテストを行うのに対して、このテストを自動化できることは、それを物語っています。このエンジニアはスタック内で他のことに集中できるので、ウォーターフォール手法を使用した従来のソフトウェアのリリースで滞りがちだったバグやソフトウェアのテストではなく、より速く、より機能的に開発することが可能になります。

インテグレーション

インテグレーションは、DevOpsのライフサイクルの中で最も重要なものです。これは、開発者がより頻繁にソースコードに変更をコミットすることを必要とするプラクティスである。これは、日次または週次ベースで可能です。

コミットするたびに、アプリケーションは自動テストフェーズを通過することができ、次のフェーズの前に問題やバグを早期に発見することができるようになります。

この段階で、「でも、うちはアプリケーションを作らずに、ソフトウェアベンダーから既製品を買っています」と言うかもしれません。心配しないでください。多くの企業がそうしていますし、これからもそうするでしょう。

また、このような知識を持つことは非常に重要です。今日は既製のソフトウェアを購入するかもしれませんが、明日やその先...次の仕事ではどうでしょうか？

デプロイメント

さて、私たちはアプリケーションを構築し、エンドユーザーの要求に対してテストを行いました。

これは、コードを本番サーバーにデプロイする段階ですが、ここが非常に面白くなるところで、86日間の残りの時間は、これらの領域に深く潜っていきます。なぜなら、アプリケーションによって、必要となるハードウェアや構成が異なるからです。そこで、アプリケーション構成管理とInfrastructure as CodeがDevOpsライフサイクルの中で重要な役割を果たすことになります。アプリケーションはコンテナ化されているかもしれませんが、仮想マシン上で実行することも可能です。そして、コンテナをオーケストレーションし、エンドユーザーが望む状態を利用できるようにする Kubernetes のようなプラットフォームにもつながっていくのです。

これらの大胆なトピックはすべて、今後数週間でさらに詳しく説明し、それらが何であり、どのような場合に使用するのかについての基礎知識を深めていきます。

モニタリング

私たちは、新しい機能や特徴を持つアプリケーションを継続的に更新し、グレムリンが発見されていないことを確認するためのテストを行っています。必要な構成とパフォーマンスを継続的に維持できる環境で、アプリケーションを実行させています。

しかし、今度は、エンドユーザーが必要とする体験を得られるかどうかを確認する必要があります。ここでは、アプリケーションのパフォーマンスが継続的に監視されていることを確認する必要があります。このフェーズでは、開発者が将来のリリースでアプリケーションを強化し、エンドユーザにより良いサービスを提供するためのより良い決定を下すことができるようになります。

また、このセクションでは、実装された機能と、エンドユーザがそれらをどのように改善したいかについてのフィードバックの輪を捉えるところでもあります。

信頼性はここでも重要な要素です。結局のところ、私たちはアプリケーションが必要とされるときはいつでも利用できるようにしたいのです。これは、継続的に監視されるべき他の監視性、セキュリティ、およびデータ管理の分野につながり、フィードバックは常に、アプリケーションを継続的に強化、更新、およびリリースするために使用することができます。

この継続的なプロセスには、FinOpsチームも関与すべきであると、特に@_ediriはコミュニティからのいくつかの意見に言及しました。アプリとデータはどこかで実行され、保存されています。リソースの観点から物事が変化した場合、そのコストがクラウド請求書に大きな財務的苦痛を与えていないことを確認するために、これを継続的に監視する必要があります。

また、上記の「DevOpsエンジニア」の話を持ち出す良い機会だと思います。世間には多くのDevOpsエンジニアのポジションがありますが、これはDevOpsのプロセスを位置づける上で理想的な方法ではありません。私が言いたいのは、コミュニティの他の人たちと話すと、DevOpsエンジニアという肩書きは誰にとってもゴールではないはずだということです。なぜなら、本当にどんなポジションでも、DevOpsプロセスやここで説明したカルチャーを採用すべきだからです。DevOpsは、Cloud-Nativeエンジニア/アーキテクト、仮想化管理者、クラウドアーキテクト/エンジニア、インフラ管理者など、様々なポジションで使用されるべきものです。これはほんの一例ですが、上記のDevOps Engineerを使用した理由は、上記のポジションやその他のポジションで使用される範囲やプロセスを強調するためです。 無料版のDeepL翻訳（www.DeepL.com/Translator）で翻訳しました。

リソース

このReadmeファイルは学習用として用意したものなので、いつでも追加リソースを受け付けています。

私のアドバイスは、以下のビデオをすべて見ること、そして上記のテキストや説明から何かを感じ取っていただけることを願っています。

ここまで来れば、ここが自分の居場所かどうかが分かるはずです。では、4日目でお会いしましょう。