🤽🏿 👩🏾‍🍳 😄 DevOpsは最新のQAを必要としていますか？ 🎀 👩🏽‍🚀 💅🏻

DevOpsについて聞いたことがありますか？たぶんあなたはQAエンジニアであり、DevOpsが原因であなたの需要が低下することを恐れていますか？または、開発者であり、DevOpsを実装する前に自分とチームをアップグレードしたいが、どこから始めればよいかわからない場合は、フードの下での回答。

ロシア語を話すDevOpsポッドキャスト「Two Devs One Ops」 Sergey bsideup Egorov（ twitter.com/bsideup ）のホストであるZeroTurnaroundのフルスタックエンジニアが質問に答えます。

セルゲイ・エゴロフ：

「...展開、インフラストラクチャの変更、システムのさまざまな部分に関する知識の欠如、変更配信の透明性、ローカル開発の複雑さ、「戦闘サーバーへの展開後の「火との戦い」... DevOpsはそれぞれに答えと推奨事項を提供します」

アプリケーションの展開は科学全体

-まず、DevOpsについて説明しましょう。 なぜこのイデオロギーは比較的短い期間で人気になったのですか？ その主な原則は何ですか？

-DevOpsは根本的に新しいもので、どこからでも来るものではないと思います。人々は、現在DevOpsアプローチの標準と見なされていることを実行していました。カバレッジは別の問題です。インフラストラクチャに参加する開発者を提供していた大企業がXサーバーに行くことを提供していた場合、それは狂ったように聞こえ、リスクが非常に高かったため、同じ人が非常に大きな切り札を持っています。そして、この切り札は経験です。他のチーム、大規模なチーム、ITの巨人のレベルの経験。確かに、リスクはどこにもなくなっておらず、「着る」可能性は完全です。しかし、一般的に、傾向は非常に良好であり、実際の問題-同じ製品の開発と提供に関与するチームの相互作用の問題を解決します。

DevOpsの主な原則について話すのは難しいです。お互いに助け合う、または何か。アプリケーションのデプロイは科学全体であり、開発者としてのあなたは、開発が途切れることなくエンドユーザーを見つけることに関心を持つべきです。針仕事をする-彼らは郵便、荷物の送付、このプロセスのニュアンスをよく知っています。誰かが自分の製品を投げたり、つぶしたり、失ったりするのを恐れているだけだからです。では、なぜ開発中のサービスを不十分に扱い、配信プロセスを気にしないのですか？

... DevOpsの主な原則について。 お互いに助け合う、または何か...

-QAはDevOpsのコンポーネントの1つと見なされます。 それらを2つの異なる方法論として比較するのは正しいのですか？

-ソフトで暖かく。 DevOpsは方法論であり、QAは製品に関する早期のフィードバックを取得し、製品が設定された要件を満たしていることを確認するプロセスです。したがって、「DevOpsエンジニア」と言うのは正しくありませんが、「QAエンジニア」はかなりの仕事です。「DevOps」という言葉を「アジャイル」に置き換えれば、これらの質問に答えることは非常に簡単です。同意します、「馬鹿げている人を見つけましょう！」、「あなたの会社には何人のアジャイルがいますか？」アジャイルトレーナーを雇います。チームはアジャイルアプローチに従います。そして、ここにあります。

-DevOpsアプローチとQAの標準アプローチの基本的な違いは何ですか？

-私自身の実践から-DevOpsアプローチでは、人々はより多くの統合テストを書き始め、開発サイクルを短縮します。継続的デリバリは、DevOps環境で変更をデリバリする完全に自然なプロセスです。これにより、QAの状況が間接的に改善され、テストに必要なビルドの変更の数が削減されます。もちろん、これらのビルドの数を増やすことはできますが、すでにバランスの問題があります。

DevOps方法論

開発者の作業はコミットで終了するのではなく、そこから始まります

-DevOpsはQAエンジニアの生活にどのように影響しますか？

-ほとんどの場合、ビルドは何らかの自動テストに既に合格しているQAに送られます。ただし、統合テストでは、QAを再現するのが難しい非常に難しいケースをテストできます。 DevOpsはあらゆる種類のツールによって非常に優れており、この問題のQAも回避されません。あらゆる種類の分散ビルドシステム、テストの並列化。一部のQAエンジニアにとって、可能な限りテスト環境に近いテスト環境を作成できることは金の価値があることは間違いありませんが、これはDevOpsアプローチにとって非常に自然なことです。

-ほとんどの場合、DevOpsは継続的デリバリーを使用します。これは、新しいリリースの展開と展開のペースが速いことを特徴としています。 1人がコードの記述、テスト、および管理機能に従事している場合、これは最終的に「ラットレース」に変わりますか？

-まあ、あなたがあなたのチームで「DevOpsエンジニア」を雇っているなら、それは変わります。 DevOpsが特定の人々に関連付けられている限り、状況はこのようなものになります。これらの特定の人々からの需要があるからです。しかし、すでにチームがDevOpsで「飽和」している場合、全員が一緒にロールアウトすることに従事しています。結局のところ、私はあなたに思い出させてください、開発者の仕事はコミットで終わるのではなく、ただそこから始まります。変更をエンドユーザーに提供することが全員の目標です。

-主なDevOpsツールは、あらゆる種類の自動化です。 その結果、このようなプロセスの起動には費用がかかります。 DevOpsを使用する価値がない境界はありますか？ 何に依存していますか？

-私は反対だと思います。 DevOpsを使用すると、クイックスタートを行ってからナットを締めることができます。たとえば、ハッカソンの1時間後に、簡単なスクリプトを使用して開発者のマシンから手で製品のプロトタイプを展開し、自動化を構成します。 MVP-最小実行可能製品アプローチに従うことが非常に重要です。これは「スケーラブルなCIサービスを設定し、スケーラブルで、美しいパイプラインを作成したときではありませんが、シェルスクリプトとjavac呼び出しを介して構築します」。私たちはすべてのことを少し行う必要があり、製品デリバリーのレイヤーの1つが他のレイヤーよりもはるかに遅れ始めたときに改善する必要があります。

主なことは、チーム全体があらゆる状況に対処できることです

-DevOpsはプロセス参加者の資格要件を高めますか？

「私はそう思う。」 DevOpsには多くのベストプラクティスが組み込まれていますが、誰もが十分なレベルでそれらを理解しているわけではありません。たとえば、2012年から12factor.net/ru/を開き、これらの12の簡単なポイントを確認します。開発者のDevOpsプロセスへの切り替え意欲、DevOpsに自然な最新のサービスを作成する能力を非常によく決定します。

しかし、良いニュースがあります-DevOpsの普及のおかげで、この資料は単純に計り知れず、たとえば10年前よりも資格の改善がはるかに簡単になりました。

-DevOpsは、複数の部門の「シームレスな」組み合わせです。 これは、社内のロジスティクスの簡素化を意味しますか？ これは会社全体の仕事にどのように影響しますか？

-正直に言うと、たとえば100人のDevOpsチームについてはほとんど考えていません。部門をそれぞれ約10人の小さなチームに分割する方がはるかに効率的ですが、同時にチームは職域を超えて、つまりタスクを完了するためにすべての適切な人員を配置する必要があります。誰かがこれを「各チームはあらゆる方向に人を置くべきだ」という事実と混同することがよくあります-これはそうではありません。人々は本質的に多面的であり、DevOpsはこれを確認するだけなので、チーム内の同じ人物がインフラストラクチャを開発および構成できます。もう1つはJenkinsのプラグインのファンであり、一般にビルドシステムに精通しています。主なことは、コードを保存するリポジトリの作成、ビルドシステムのセットアップ、運用環境でのクラスターの展開、監視システムの通知への応答など、チーム全体があらゆる状況に対処できることです。

-DevOpsは必要なツールのセットで際立っていますか？ それらの何がそんなに特別なのですか？

-まあ、開発者にサーバーを扱わせてください、そして、彼はそれらに対処しません。彼はサーバー用に開発します。開発者...彼らは怠け者です。つまり、すべてを自動化することを意味します。そのため、DevOpsの普及により、あらゆる種類のシステムまたはその生まれ変わりが非常に多様になりました。サービスオーケストレーションのリーダーであるKubernetesを取り上げてください。DevOps（これを含む）についての会話はほとんどありません。しかし、これは新しいものですか？いいえ、グーグルは彼らのボーグを「すべてのために」実現しただけで、それを十数年以上使用していました。

Dockerに言及するしかありません-結局のところ、新しいコンテナーは非常に長い間存在していませんでしたが、DevOpsをきっかけに人気が出たのは、このような複雑なシステムの使いやすさでした。

ユニバーサルツールはそれ自体として存在しません。 DevOps-それはツールだけではなく、「これ、これ、これを取る-DevOpsがあります」と言うことはできません。

製品と環境、クラウド内またはサーバーに依存します。 DevOpsツールの明確なリーダーは、開発とテストの両方の自動化、および変更の配信であるとしか言えません。 Mesos、Kubernetes、Docker Swarmなど、APIを使用してインフラストラクチャを操作できるオーケストレーションシステムが多数あります。これらは、「これはDevOps」と誤解されることが多い部分を自動化するのに役立ちます。サーバーを個別の面倒を見る代わりに、問題のあるサーバーを簡単に再作成できるフェースレス「群れ」に変えるツール。

-最新のDevOpsにはどのような問題がありますか？

-レガシーアプリケーションは最大の問題の1つだと思います。「モノリシックEARをここでWebSphereのDockerコンテナにプッシュしようとしましたが、何かが機能せず、DevOpsが機能しません」というのは非常に人気のある言葉です。 DevOpsは、多くの開発上の問題を回避するのに役立ちますが、ほとんどの問題は解決しません。

また、DevOpsチームを効果的に編成する人を見つけるのも簡単ではないと思います。そのような人々は、オーガナイザーの経験を持ちながら、最新のテクノロジーに遅れずについていく必要があります（ほとんどのDevOpsテクノロジーは若いため、これなしではどこにもありません）。 10x開発者についてのフレーズを覚えていますか？「残りの5人を助ける人は、生産性が2倍になります。」これは、チームでDevOpsを宣伝する人々を非常によく説明していると思います。また、DevOpsがもたらすプロセスの変化の重要性を他の人々に伝えるために、他の人々のアプローチを変えることは非常に難しい場合があります。確かに、結果は手段を正当化することが多く、成功したDevOpsチームはほとんどの場合、「悪夢のような」古いプロセスを思い出します。

-会社の仕事におけるDevOpsの実装について教えてください。 それはどのように始まり、すべてが「機能した」ことをどのように理解するのですか？

-各チームは、プロセスの問題を知っています。最終的に、プロセスの問題、異なる企業の同じ問題により、概念としてのDevOpsが生まれました。

製品開発と配信プロセスを分析し、ボトルネックを見つけます。展開、インフラストラクチャの変更、システムのさまざまな部分に関する知識の欠如、変更配信の透明性、ローカル開発の複雑さ、戦闘サーバーへの展開後の「ファイティングファイア」-誰もがこのリストでおなじみのアイテム、またはいくつかを見つけると思います。そして、それぞれについて、DevOpsは回答と推奨事項を提供します。同様に問題が解決した場合は、DevOpsがあなたのためではなくあなたのために働き始めていることを示す良い指標です。

-2016年6月、devops.com は「DevOpsがQAを殺している方法」というタイトルの記事を公開しました。これは、DevOpsにはQAは必要ないと述べています。 この観点についてどのようにコメントできますか？

検索クエリ統計「sqa jobs」および「devops jobs」

-プロセスとしてのQAはどこにも行きません。はい、ますます多くのテスト自動化が登場し、実際のユーザーでA / Bテストを行うのが簡単になりますが、ここに問題があります...プログラマーは常にコードが機能することを期待しています。したがって、プログラマーが自分のコードをテストするとき、他の動作を期待することはなく、自分のコードが機能することを確認するテストを作成します。優れたQAエンジニアは、コードを見ず、製品を見、製品でできること、できないことを考え、製品が仕様を満たしているかどうかをチェックします。たとえ何千ものテストを書いたとしても、それらがすべてプログラマーによって書かれていれば、常にバグが発生します。したがって、QA、管理者、およびその他すべてのユーザーは、DevOpsが必要なため、静かに眠ることができます。

それまでの間、DevOpsは世界のすべてのチームを飽和させていないため、 2016年のハイゼンバッグモスクワ会議に参加することをお勧めします。開発者とテクライドの両方にとって興味深いものになります。

レポートのリスト：

DevOpsは最新のQAを必要としていますか？

アプリケーションの展開は科学全体

開発者の作業はコミットで終了するのではなく、そこから始まります

主なことは、チーム全体があらゆる状況に対処できることです

More articles: