開発者向けの DevOps のベスト プラクティス。 アントン・ボイコ (2017)

このレポートでは、開発者の観点から、いくつかの DevOps 実践について説明します。 通常、DevOps に参加するすべてのエンジニアは、すでに数年間の管理経験を持っています。 しかし、これはここに開発者の居場所がないという意味ではありません。 多くの場合、開発者は「その日の次に緊急に重大なバグ」を修正するのに忙しく、DevOps 分野をざっと調べる時間さえありません。 著者の理解では、DevOps は第一に常識です。 第二に、より効果的になれる機会です。 あなたが開発者であり、常識を持ち、チームプレーヤーとしてより効果的になりたいと考えている場合は、このレポートが最適です。

自己紹介をさせてください。この部屋に私のことを知らない人がいることは承知しています。 私の名前はアントン ボイコです。Microsoft Azure MVP です。 MVPとは何ですか？ これはモデル-ビュー-プレゼンターです。 Model-View-Presenter はまさに私です。

さらに、私は現在、Ciklum でソリューション アーキテクトの役職を務めています。 そしてつい最近、私は自分自身にとても美しいドメインを購入し、いつもプレゼンテーションで見せる自分の電子メールを更新しました。 me [dog] bykoant.pro までメールをお送りください。 質問がある場合はメールでご連絡ください。 私は通常それらに答えます。 唯一のことは、政治と宗教という XNUMX つのトピックに関連する質問を電子メールで受け取りたくないということです。 その他のことについては、電子メールで私に書いていただけます。 時間が経てばお答えします。

私自身について一言：

• 私はこの分野に10年ほど携わっています。
• 私はマイクロソフトで働いていました。
• 私は、2014 年に設立したウクライナの Azure コミュニティの創設者です。 そして私たちはそれを今でも持っており、開発中です。
• 私はウクライナで主催している Azure カンファレンスの創設者の父親でもあります。
• また、キエフでの Global Azure Bootcamp の開催も手伝っています。
• 先ほども言いましたが、私は Microsoft Azure MVP です。
• 私はカンファレンスでよく講演します。 私はカンファレンスで話すのが大好きです。 この40年間でXNUMX回ほど出演させていただきました。 ウクライナ、ベラルーシ、ポーランド、ブルガリア、スウェーデン、デンマーク、オランダ、スペインを通過したり、ヨーロッパの他の国を経由したりした場合、流れの中でクラウドをテーマにしたカンファレンスに参加すると、スピーカーのリストに私が載っているかもしれません。
• 私もスタートレックのファンです。

アジェンダについて少しお話しましょう。 私たちのアジェンダは非常にシンプルです。

• DevOps とは何かについて説明します。 これがなぜ重要なのかを話しましょう。 以前は、DevOps というキーワードを履歴書に書くと、すぐに +500 ドルの給与が受け取れました。 たとえば、給与を 500 ドル増やすためには、履歴書にブロックチェーンについて書く必要があります。
• そして、これが何であるかを少し理解したら、DevOps プラクティスとは何かについて話します。 ただし、DevOps 全般のコンテキストではなく、開発者にとって興味深いと思われる DevOps の実践についてです。 なぜそれらがあなたにとって興味深いのかを説明します。 なぜこれを行う必要があるのか​​、そしてそれがどのように痛みを軽減するのに役立つのかを説明します。

多くの人が見せる伝統的な絵。 これは多くのプロジェクトで起こっていることです。 このとき、当社のソフトウェアをサポートする開発部門と運用部門が存在します。 そして、これらの部門は相互に連絡しません。

おそらく、DevOps 部門や運用部門ではそれをそれほどはっきりと感じることができなかったとしても、開発部門や QA 部門に例えることができるでしょう。 ソフトウェアを開発する人もいれば、開発者の観点から見て悪い QA の人もいます。 たとえば、私が素晴らしいコードをリポジトリにコミットすると、そこに悪党が座っていて、このコードを私に返してきて、あなたのコードは間違っていると言います。

これはすべて、人々が互いにコミュニケーションをとっていないために起こります。 そして、彼らはいくつかのパッケージやアプリケーションを誤解の壁を乗り越えて互いに投げ合い、それを使って何かをしようとします。

DevOps 文化が破壊するように設計されているのはまさにこの壁です。 人々が互いにコミュニケーションし、少なくともプロジェクト内のさまざまな人々が何をしているのか、そして彼らの仕事がなぜ重要なのかを理解するように強制します。

そして、DevOps について話すとき、DevOps とはプロジェクトに継続的インテグレーションが行われるときであると誰かが言うでしょう。 プロジェクトが「コードとしてのインフラストラクチャ」プラクティスを実装する場合が DevOps であると言う人もいます。 DevOps への最初のステップは機能分岐と機能フラグであると言う人もいます。

本質的に、これはすべてそれ自体が真実です。 しかし、これらは私たちが行っている究極の実践にすぎません。 これらの実践に移る前に、このスライドを参照することをお勧めします。このスライドでは、会社のプロジェクトに Dev-Ops 方法論を実装する 3 つの段階が示されています。

このスライドには 3 番目の非公式の名前もあります。 DevOps の 3 銃士が何であるかをオンラインで検索して確認できます。 この記事が見つかる可能性があります。 なぜ三銃士なのか？ その下には「人、プロセス、製品」と書かれています。 PPP – ポルトス、ポルトス、そしてポルトス。 DevOpsの三銃士をご紹介します。 この記事では、これが重要な理由とそれに伴う内容について詳しく説明します。

DevOps 文化の実装を開始するときは、次の順序で実装することが非常に重要です。

最初は人々と話す必要があります。 そして、それが何なのか、そしてそこからどのように利益を得られるのかを人々に説明する必要があります。

私たちのカンファレンスは DotNet Fest と呼ばれています。 そして、主催者が私に言ったように、ここには主に開発者の聴衆を招待しました。そのため、会場にいるほとんどの人が開発に関わっていることを願っています。

私たちは人々について話し、開発者が毎日何をしたいのかについて話します。 彼らが一番望んでいることは何でしょうか？ 彼らは、新しいコードを書き、新しいフレームワークを使用し、新しい機能を作成したいと考えています。 開発者が最も望まないことは何ですか? 古いバグを修正します。 あなたも私に同意してくれることを願っています。 これが開発者が望んでいることです。 彼らは新しい機能を書きたいのですが、バグを修正したいのではありません。

特定の開発者が生み出すバグの数は、腕がどれだけ真っすぐに伸びているか、そして尻のポケットからではなく肩からどれだけ伸びているかによって決まります。 しかし、それでも、大規模なプロジェクトの場合、すべてを追跡することが不可能な場合があるため、より安定した高品質のコードを作成するのに役立ついくつかのアプローチを使用するとよいでしょう。

QAが最も望んでいることは何ですか? 彼らがホールにいるかどうかはわかりません。 QA を受けたことがないので、QA を受けたいと言うのは難しいです。 そして、彼らに悪気はありません、私が決してそうでないことを願っていると言われるでしょう。 しかし、私が彼らの仕事を無意味で役に立たないと考えるからではなく、私はこの仕事を効率的にこなせる人間ではないと考えているので、それをやろうとさえしません。 しかし、私が理解しているところによると、QA が最も嫌がることは、午前中に作業を行って、ある種の回帰テストを常に実行し、3 スプリント前に開発者に報告したのと同じバグを踏んで、次のように言うことです。 , ムッシュ・ダルタニャン、このバグを直してください。 するとムッシュ・ダルタニャンは「はい、はい、はい、もう直しましたよ」と答えた。 そして、途中で 5 つのバグを修正し、XNUMX つのバグを作成したのはなぜでしょうか。

このソリューションを運用環境でサポートしている人々は、このソリューションがバグなしで機能することを望んでいます。そうすれば、一般の人がバーに行く毎週金曜日にサーバーを再起動する必要がなくなります。 開発者は金曜日にデプロイし、管理者は土曜日までこのデプロイメントを立ち上げて修正しようとしました。

そして、同じ問題を解決することを目的としていると人々に説明すると、プロセスの形式化に進むことができます。 それは非常に重要です。 なぜ？ なぜなら、「形式化」というときは、少なくともナプキンのどこかにプロセスがどのように行われるかを説明することが重要だからです。 たとえば、QA 環境や運用環境にデプロイする場合は、常にこの順序で行われることを理解する必要があります。これらの段階では、たとえば、自動単体テストや UI テストが実行されます。 デプロイ後、デプロイがうまくいったか失敗したかを確認します。 ただし、運用環境にデプロイするときに何度も繰り返す必要があるアクションの明確なリストがすでにあります。

そして、プロセスが正式化されて初めて、これらのプロセスの自動化に役立つ製品を選択し始めます。

残念ながら、これが逆に起こるのをよく見かけます。 「DevOps」という言葉を聞くと、すぐに Jenkins のインストールを勧める人は、Jenkins をインストールすればすぐに DevOps が使えるようになると信じているからです。 彼らは Jenkins をインストールし、Jenkins Web サイトの「ハウツー」記事を読み、そのハウツー記事にプロセスを詰め込もうとしました。そして、人々のところに来て、この本にはこうする必要があると書いてあると言って人々を屈服させました。だから私たちはこのようにします。

Jenkinsが悪いツールだというわけではありません。 決してそんなことを言いたいわけではありません。 しかし、これは製品の XNUMX つにすぎません。 どの製品を使用するかは、最初の決定ではなく、最後の決定であるべきです。 製品は、文化やアプローチの実装によって推進されるべきではありません。 これは理解することが非常に重要であるため、私はこのスライドに非常に多くの時間を費やし、このすべてを長々と説明しました。

DevOps の実践全般について話しましょう。 彼らは何ですか？ 違いはなんですか？ 試着するにはどうすればよいですか？ なぜそれらが重要なのでしょうか?

あなたが最初に聞いたことがあるかもしれないプラクティスは、継続的インテグレーションと呼ばれます。 おそらく、プロジェクトの誰かが継続的インテグレーション (CI) を使用している可能性があります。

最大の問題は、私が人に「このプロジェクトに CI はいますか?」と尋ねることが最も多いことです。 そして彼は「はい」と言い、何をしているのかと尋ねると、彼は自動化プロセス全体を完全に説明してくれました。 これは完全に真実ではありません。

実際、CI の実践は、さまざまな人々が書いたコードをある種の単一のコード ベースに統合することだけを目的としています。 それだけです。

通常、CI に加えて、継続的デプロイメント、リリース管理など、他の実践も途中で行われますが、それについては後ほど説明します。

CI 自体は、さまざまな人々がコードを記述し、このコードは単一のコード ベースに継続的に統合される必要があることを示しています。

これは何をもたらすのでしょうか?また、なぜ重要なのでしょうか? DotNet があれば、それはコンパイル済み言語なので、アプリケーションをコンパイルできます。 コンパイルできれば、これはすでに良い兆候です。 これはまだ何も意味しませんが、少なくともコンパイルできるという最初の良い兆候です。

次に、いくつかのテストを実行します。これも別の練習です。 テストはすべて緑色です。これは XNUMX 番目の良い兆候です。 しかし、繰り返しますが、これには何の意味もありません。

しかし、なぜこんなことをするのでしょうか？ 今日お話しするすべての実践は、ほぼ同じ価値、つまりほぼ同じ利点をもたらし、ほぼ同じ方法で測定されます。

まず、配達のスピードを上げることができます。 これにより、どのようにして配送を早めることができるのでしょうか? コードベースに新しい変更を加えると、すぐにこのコードで何かを実行してみることができます。 木曜日に QA 環境にリリースし、ここですぐに実行するため、木曜日が来るまで待ちません。

私の人生の悲しい話をひとつお話します。 それは遠い昔、私がまだ若くてハンサムだった頃のことです。 今、私はすでに若く、美しく、賢く、控えめです。 少し前に、私はあるプロジェクトに参加していました。 私たちは約 30 人の開発者からなる大規模なチームを抱えていました。 そして、約 10 年間にわたって開発された大規模なエンタープライズ プロジェクトがありました。 そして、私たちはさまざまな支店を持っていました。 リポジトリには、開発者がそこを歩くブランチがありました。 また、運用中のコードのバージョンを表示するブランチもありました。

本番ブランチは、開発者が利用できるブランチより 3 か月遅れていました。 これはどういう意味ですか？ これは、開発者のせいで、開発者がそれを許可したため、また QA のせいで、QA がそれを調べたために、どこかにバグが発生してすぐに本番環境に移行するということを意味します。実稼働用のホットフィックスのタスクが必要な場合は、3 か月前のコード変更をロールバックする必要があります。 3か月前のことを思い出して、そこで修正しなければなりません。

この経験がまだない場合は、自宅のプロジェクトで試してみてください。 重要なことは、市販のものでは試さないことです。 数行のコードを書いて、XNUMX か月間忘れてから、戻ってきて、そのコード行が何についてのもので、どのように修正または最適化できるかを簡単に説明してみます。 とてもとてもエキサイティングな体験です。

継続的インテグレーションを実践している場合は、コードを作成したらすぐに、すぐに多くの自動化ツールを使用してそれをチェックすることができます。 これで全体像がわかるわけではないかもしれませんが、少なくともリスクの一部は取り除くことができます。 潜在的なバグがある場合は、今すぐ、つまり文字通り数分以内にそれを知ることができます。 3 か月前に戻す必要はありません。 2分だけ巻き戻す必要があります。 高性能のコーヒーマシンではコーヒーを淹れるのに 2 分もかからないので、これは非常に素晴らしいことです。

これには、各プロジェクトで何度も繰り返すことができるという価値があります。 セットアップしたものだけではありません。 実践自体を繰り返すことができ、プロジェクトに新たな変更を加えるたびに CI 自体が繰り返されます。 これにより、チームがより効率的に作業できるため、リソースを最適化できます。 3 か月前に作業したコードからバグが発生するという状況はもう発生しません。 座って最初の XNUMX 時間を費やして、何が起こったのかを理解して、何かを修正し始める前にコンテキストの本質を理解しようとすると、コンテキストが切り替わることはなくなります。

この実践の成功または失敗をどのように測定できるでしょうか? 私たちが CI プロジェクトに実装した内容を上司に報告すると、上司はなんとかなんとかと聞きます。 それを実装したのはいいのですが、なぜ、それが私たちに何をもたらしたのか、それをどのように測定するのか、どの程度正しく実装しているのか、それとも間違っているのか?

XNUMX つ目は、CI のおかげで、コードが潜在的により安定しているため、より頻繁に、より頻繁にデプロイできることです。 同様に、コードのどこが間違っているのかという答えを今ここでシステムから受け取ることができるため、エラーを見つける時間も短縮され、このエラーを修正する時間も短縮されます。

私たちが行っているもう XNUMX つの実践は、自動テストの実践です。これは、ほとんどの場合、CI の実践に付随して行われます。 それらは密接に関係しています。

ここで理解することが重要なことは何でしょうか? 私たちのテストは異なることを理解することが重要です。 そして、それぞれの自動テストは、それぞれの問題を解決することを目的としています。 たとえば、モジュールを個別にテストできる単体テストがあります。 真空中ではどのように機能するのでしょうか? これはいい。

また、さまざまなモジュールがどのように相互に統合されるかを理解できる統合テストもあります。 それも良いですね。

UI の自動化テストにより、UI の動作が顧客が設定した特定の要件をどの程度満たしているかを確認できる場合があります。

実行する特定のテストは、実行頻度に影響を与える可能性があります。 単体テストは通常​​、短く小さく書かれます。 そしてそれらは定期的に起動することができます。

UI 自動テストについて話している場合、プロジェクトが小規模であることが望ましいです。 UI 自動化テストには、ある程度の時間がかかる場合があります。 ただし、大規模なプロジェクトの UI 自動化テストは通常​​、数時間かかります。 それも数時間なら大丈夫です。 唯一のことは、ビルドごとにそれらを実行することに意味がないということです。 夜間に実行するのは理にかなっています。 そして、テスターも開発者も含めて全員が朝出勤すると、夜に UI 自動テストを実行してこのような結果が得られたという、ある種のレポートを受け取りました。 そしてここで、製品がいくつかの要件を満たしていることをチェックするサーバーの XNUMX 時間の作業は、たとえそれが食料と感謝のために働いているジュニア QA エンジニアであっても、同じ QA エンジニアの XNUMX 時間の作業よりもはるかに安くなります。 それでも、機械をXNUMX時間稼働させれば安くなります。 だからこそ、そこに投資するのは理にかなっているのです。

私が取り組んでいる別のプロジェクトがあります。 このプロジェクトでは 4 週間のスプリントがありました。 このプロジェクトは大規模であり、金融​​セクターにとって重要であり、間違いを犯すことはできませんでした。 4 週間のスプリントの後、開発サイクルの後にテスト プロセスが続き、さらに XNUMX 週間かかりました。 悲劇の規模を想像してみてください。 私たちは XNUMX 週間かけてコードを書き、その後 CodeFreeze で実行し、新しいバージョンのアプリケーションにパッケージ化して、テスターに​​ロールアウトします。 テスターはさらに XNUMX 週間テストします。 彼らがテストしている間、私たちは彼らのためにさらに XNUMX つのバージョンを準備する時間があります。 これは本当に悲しいケースです。

そして、生産性を高めたいのであれば、自動テストの実践を導入するのが理にかなっていると伝えました。なぜなら、これが今ここであなたを傷つけているからです。

継続的展開を実践します。 素晴らしい、ビルドが完了しました。 これはもういいですね。 コードがコンパイルされました。 このビルドを何らかの環境にデプロイしてみると良いでしょう。 開発者向けの環境で考えてみましょう。

どうしてそれが重要ですか？ まず、展開プロセス自体がどの程度成功しているかを確認できます。 私はこのようなプロジェクトに遭遇したことがあります。「アプリケーションの新しいバージョンはどうやってデプロイするのですか?」と尋ねると、彼らはこう言います。「私たちはそれを組み立てて、zip アーカイブに圧縮します。 管理人宛にメールにて送信させていただきます。 管理者はこのアーカイブをダウンロードして展開します。 そしてオフィス全体が、サーバーが新しいバージョンを取得することを祈り始めます。」

簡単なことから始めましょう。 たとえば、CSS をアーカイブに入れるのを忘れたり、JavaScript ファイル名のハッシュタグを変更するのを忘れたりします。 そして、サーバーにリクエストを行うと、ブラウザはこの JavaScript ファイルがすでに存在すると考え、ダウンロードしないことを決定します。 そして古いバージョンには何かが欠けていました。 一般に、多くの問題が発生する可能性があります。 したがって、継続的デプロイメントを実践すると、クリーンな参照イメージを取得し、それを完全にクリーンな新しい環境にアップロードした場合に何が起こるかを少なくともテストできます。 これがどこにつながるかがわかります。

また、相互にコードを統合する場合、つまり、 コマンドの間で、これにより UI 上でどのように見えるかを確認することもできます。

バニラ Java スクリプトが多数使用されている場合に発生する問題の XNUMX つは、XNUMX 人の開発者がウィンドウ オブジェクト内で同じ名前の変数を無謀に宣言したことです。 あとは、運次第。 XNUMX 番目に取り出された Java スクリプト ファイルは、もう一方の JavaScript ファイルの変更を上書きします。 それもとても楽しみです。 あることはある人にはうまくいきますが、別のことは別の人にはうまくいきません。 そして、それがすべて本番環境で実現すると、それは「素晴らしい」ことになります。

次に行う実践は、自動復元の実践、つまりアプリケーションの前のバージョンにロールバックすることです。

これが開発者にとってなぜ重要なのでしょうか? コンピューターが大きく、プログラムが小さかった、遠い遠い 90 年代を覚えている人がまだいます。 そして、Web 開発への唯一の方法は PHP を使用することでした。 PHP が悪い言語であるというわけではありませんが、実際にはそうです。

しかし、問題は違っていました。 新しいバージョンの PHP サイトをデプロイするとき、どのようにデプロイしましたか? ほとんどの場合、Far Manager などを開きました。 そしてこれらのファイルをFTPにアップロードしました。 そして突然、小さな小さなバグがあることに気づきました。たとえば、セミコロンを付けるのを忘れたり、データベースのパスワードを変更するのを忘れたり、データベースのパスワードはローカルホスト上にあります。 そして、すぐに FTP に接続し、そこでファイルを編集することにしました。 これはただの火事だ！ これは90年代に流行ったものです。

しかし、カレンダーを見ていない方のために説明すると、90 年代はほぼ 30 年前です。 今では、すべてが少し違った形で起こっています。 そして、彼らが次のように言ったときの悲劇の規模を想像してみてください。「本番環境にデプロイしましたが、そこで何か問題が発生しました。 これが FTP ログインとパスワードです。本番環境に接続して、そこですぐに修正してください。」 あなたがチャック・ノリスなら、これはうまくいきます。 そうしないと、10 つのバグを修正すると、さらに XNUMX のバグが発生する危険があります。だからこそ、以前のバージョンにロールバックすることで多くのことを達成できるのです。

たとえ何か悪いものがどこかに侵入したとしても、それは悪いものではありますが、致命的ではありません。 以前のバージョンにロールバックできます。 用語で理解しやすい場合は、それをバックアップと呼びます。 この以前のバージョンにロールバックすることができ、ユーザーは引き続き製品を使用でき、十分なバッファ時間が確保されます。 慌てずに落ち着いて、これらすべてを取得してローカルでテストし、修正して、新しいバージョンをアップロードできます。 これを行うのは本当に理にかなっています。

ここで、前の XNUMX つの実践を何らかの方法で組み合わせてみましょう。 XNUMX つ目は「リリース管理」です。

古典的な形式の継続的デプロイメントについて話すとき、リポジトリのブランチからコードを取得し、コンパイルしてデプロイする必要があると言います。 同じ環境であれば良いですね。 複数の環境がある場合、同じコミットからであっても、毎回コードをプルする必要があることを意味します。 毎回それを取り出し、毎回ビルドし、新しい環境にデプロイします。 まず、これは時間です。プロジェクトを構築するのに、90 年代に開発された大規模なプロジェクトがある場合、数時間かかることがあります。

それに加えて、もう一つ悲しいことがあります。 ビルドするときは、同じマシン上で同じソースをビルドすることになりますが、このマシンが前回のビルド時と同じ状態であるという保証はありません。

誰かがやって来て DotNet を更新したり、逆に誰かが何かを削除したりしたとします。 そして、認知的不協和が発生し、XNUMX週間前のこのコミットからビルドを構築していてすべてがうまくいっていましたが、今では同じマシン、同じコミット、同じコードを構築しようとしているように見えますが、機能していません。 。 あなたはこの問題に長い間対処しなければなりませんが、それを理解できるかどうかは事実ではありません。 少なくとも、神経をかなり損なうことになります。

したがって、リリース管理の実践では、アーティファクト リポジトリ、ギャラリー、ライブラリと呼ばれる追加の抽象化を導入することを推奨しています。 好きな名前を付けることができます。

主なアイデアは、そこに何らかのコミットがあるとすぐに、たとえば、さまざまな環境にデプロイする準備ができているブランチに、このコミットからアプリケーションとこのアプリケーションに必要なものすべてを収集し、それをパッケージ化するということです。 zip アーカイブに圧縮し、信頼できるストレージに保存します。 そして、このストレージからいつでもこの zip アーカイブを取得できます。

次に、それを取得して、開発環境に自動的にデプロイします。 私たちはそこでレースをし、すべてがうまくいったらステージに上がります。 すべてが順調であれば、同じアーカイブ、同じバイナリを XNUMX 回だけコンパイルして実稼働環境にデプロイします。

さらに、このようなギャラリーがあると、前のバージョンへのロールバックについて説明した最後のスライドで説明したリスクに対処するのにも役立ちます。 間違ったものを誤ってデプロイしてしまった場合は、いつでもこのギャラリーから他の以前のバージョンを取得し、同じ方法でこれらの環境へのデプロイを取り消すことができます。 これにより、何か問題が発生した場合に、以前のバージョンに簡単にロールバックできます。

もう一つ素晴らしい実践があります。 皆さんも私も、アプリケーションを以前のバージョンにロールバックすると、以前のバージョンのインフラストラクチャも必要になる可能性があることを理解しています。

仮想インフラストラクチャについて話すとき、多くの人はこれは管理者が設定するものだと考えています。 また、たとえば、アプリケーションの新しいバージョンをテストするための新しいサーバーを取得する必要がある場合は、管理者または Devops にチケットを作成する必要があります。 Devops ではこれに 3 週間かかります。 そして 3 週間後、3 つのコア、XNUMX ギガバイトの RAM、および DotNet のない Windows サーバーを備えた仮想マシンをインストールしたことが通知されます。 あなたはこう言います。「でも、私は DotNet が欲しかったのです。」 彼ら：「わかりました、XNUMX週間後にまた来てください。」

その考え方は、Infrastructure as Code の実践を使用することで、仮想インフラストラクチャを単なる別のリソースとして扱うことができるということです。

おそらく、DotNet でアプリケーションを開発している人は、Entity Framework というライブラリについて聞いたことがあるかもしれません。 また、Entity Framework が Microsoft が積極的に推進しているアプローチの XNUMX つであることを聞いたことがあるかもしれません。 データベースを操作する場合、これは Code First と呼ばれるアプローチです。 これは、データベースをどのように見せたいかをコードで記述するときです。 次に、アプリケーションをデプロイします。 データベースに接続し、どのテーブルが存在するか、どのテーブルが存在しないかを自ら判断し、必要なものをすべて作成します。

インフラストラクチャでも同じことができます。 プロジェクトにデータベースが必要かどうか、またはプロジェクトに Windows サーバーが必要かどうかに違いはありません。 それは単なるリソースです。 また、このリソースの作成と構成を自動化できます。 したがって、新しいコンセプトや新しいアプローチをテストするたびに、devops へのチケットを作成する必要はなく、既製のテンプレートや既製のスクリプトから独自に分離されたインフラストラクチャをデプロイして実行するだけで済みます。あなたの実験はすべてそこにあります。 これを削除し、結果を取得し、それについてさらに詳しく報告することができます。

次の実践方法は、これも存在しており、重要ですが、使用している人はほとんどいません。アプリケーション パフォーマンスの監視です。

アプリケーション パフォーマンスの監視について言いたいことは XNUMX つだけです。 この実践で最も重要なことは何ですか? これは、アプリケーション パフォーマンスの監視がアパートの修理とほぼ同じことを意味します。 これは最終状態ではなく、プロセスです。 定期的に行う必要があります。

良い意味で、ほぼすべてのビルドでアプリケーション パフォーマンスの監視を実行するのは良いことですが、ご理解のとおり、これは常に可能であるわけではありません。 ただし、少なくともリリースごとに実行する必要があります。

どうしてそれが重要ですか？ 突然パフォーマンスが低下した場合は、その理由を明確に理解する必要があるからです。 たとえば、チームに XNUMX 週間のスプリントがある場合は、少なくとも XNUMX 週間に XNUMX 回、明確に固定されたプロセッサ、RAM、ディスクなどを備えた別のサーバーにアプリケーションをデプロイする必要があります。そして、それらと同じパフォーマンス テストを実行する必要があります。 。 結果が得られます。 前回のスプリントからどのように変化したかを確認してください。

そして、ドローダウンがどこかで急激に下がったことがわかった場合、それは単に過去 XNUMX 週間に起こった変化が原因であることを意味します。 これにより、問題をより迅速に特定して解決できるようになります。 繰り返しますが、これらは、どれだけ成功したかを測定するための指標とほぼ同じです。

次に行う演習は、構成管理の演習です。 これを真剣に受け止めている人はほとんどいません。 しかし、信じてください、これは実際には非常に深刻な問題です。

最近面白い話がありました。 彼らは私のところに来て、「アプリケーションのセキュリティ監査の実施に協力してください」と言いました。 私たちは長い間一緒にコードを見て、アプリケーションについて話し、図を描きました。 プラスまたはマイナスで、すべてが論理的で、理解でき、安全でしたが、XNUMXつだけ、しかし！ 彼らはソース管理に設定ファイルを持っていました。これには、IP データベースを使用した本番環境からの設定ファイルや、これらのデータベースに接続するためのログインとパスワードなどが含まれていました。

そして私はこう言います。「皆さん、ファイアウォールで運用環境を閉じていますが、運用データベースのログインとパスワードがソース管理にあり、開発者なら誰でもそれを読み取ることができるという事実は、すでに大きなセキュリティ リスクです。 。 そして、コードの観点からアプリケーションがどれほど安全であるとしても、それをソース管理に残しておけば、どこの監査もパスすることはできません。」 それは私が話しているものです。

構成管理。 異なる環境では異なる構成が使用される場合があります。 たとえば、QA、デモ、実稼働環境などのデータベースに異なるログインとパスワードを使用する場合があります。

この構成は自動化することもできます。 常にアプリケーション自体から分離する必要があります。 なぜ？ アプリケーションを一度構築すると、アプリケーションは、SQL サーバーに接続するときに、特定の IP を介して接続するか、またはこれこれの IP を介して接続するかを気にしないため、同じように動作するはずです。 したがって、突然、あなたの誰かがまだコード内の接続文字列をハードコーディングしている場合は、私と同じプロジェクトに参加していることに気付いたら、私があなたを見つけて罰することを覚えておいてください。 これは常に、web.config などの別の構成に配置されます。

そして、この構成はすでに個別に管理されています。つまり、開発者と管理者が同じ部屋に来て座ることができるのはまさにこの瞬間です。 そして開発者は次のように言うことができます。「ほら、これが私のアプリケーションのバイナリです。 彼らが働きます。 アプリケーションが動作するにはデータベースが必要です。 ここでバイナリの隣にファイルがあります。 このファイルでは、このフィールドはログインを担当し、これはパスワードを担当し、これは IP を担当します。 どこにでも導入してください。」 そして、管理者にとってもそれはシンプルかつ明確です。 この構成を管理することで、実際にどこにでも展開できます。

そして、私が話したい最後の実践は、クラウドに非常に非常に関連した実践です。 クラウドで作業する場合、最大の効果が得られます。 これは環境の自動削除です。

このカンファレンスには、私が一緒に働いているチームから何人か参加していることは知っています。 そして、私が一緒に働くすべてのチームでは、この習慣を採用しています。

なぜ？ もちろん、各開発者が 24 時間年中無休で動作する仮想マシンを持っていれば素晴らしいでしょう。 しかし、おそらくこれはあなたにとってニュースであり、おそらく注意を払っていなかったかもしれませんが、開発者自身は7時間24日働いているわけではありません。 開発者は通常、7 日 8 時間労働します。 たとえ早く出勤しても、昼食をたっぷり食べて、その間にジムに通っています。 開発者が実際にこれらのリソースを使用する時間を 12 日 5 時間としましょう。 当社の法律によれば、週 7 日のうち XNUMX 日が労働日とみなされます。

したがって、平日はこのマシンは 24 時間稼働するのではなく、12 時間だけ稼働する必要があり、週末にはこのマシンはまったく稼働しないはずです。 すべてが非常に単純であるように思えますが、ここで言うべき重要なことは何でしょうか？ この基本的なスケジュールでこの簡単な実践を実装することにより、これらの環境を維持するコストを 70% 削減できます。つまり、開発、QA、デモ、環境の価格を 3 で割ったことになります。

問題は、残りのお金をどうするかということです。 たとえば、開発者は ReSharper をまだ購入していない場合は購入する必要があります。 またはカクテルパーティーを開いてください。 以前は、開発と QA の両方が放牧する 3 つの環境があり、それだけだった場合、今後は分離され、相互に干渉しない XNUMX つの異なる環境を作成できるようになります。

継続的なパフォーマンス測定を含むスライドに関して、プロジェクトのデータベースに 1 件のレコードがあり、000 か月後には XNUMX 万件になった場合、パフォーマンスをどのように比較できますか? その理由を理解するにはどうすればよいですか?また、パフォーマンスを測定する意味は何ですか?

常に同じリソースでパフォーマンスを測定する必要があるため、これは良い質問です。 つまり、新しいコードをロールアウトし、新しいコードのパフォーマンスを測定します。 たとえば、さまざまなパフォーマンス シナリオをテストする必要があります。たとえば、ユーザーが 1 人でデータベース サイズが 000 GB の軽負荷時にアプリケーションがどのように動作するかをテストしたいとします。 計測して数値を出しました。 次に、別のシナリオを考えます。 たとえば、ユーザーが 5 人、データベース サイズが 5 テラバイトだとします。 私たちは結果を受け取り、それを思い出しました。

ここで何が重要ですか? ここで重要なことは、シナリオ、データ量、同時ユーザー数などによっては、特定の制限に遭遇する可能性があるということです。 たとえば、ネットワーク カードの限界、ハード ドライブの限界、プロセッサ機能の限界などです。 これはあなたが理解することが重要なことです。 さまざまなシナリオで、特定の制限に遭遇することがあります。 そして、数字を打つときはその数字を理解する必要があります。

特別なテスト環境でパフォーマンスを測定することについて話しているのでしょうか? つまり、これは本番ではないということですか？

はい、これは本番環境ではなく、テスト環境です。以前の測定値と比較できるように、常に同じ環境です。

わかった、ありがとう！

ご質問がなければ、これで終了できると思います。 ありがとう！

出所： habr.com