DevOpsはSaaS製品を持つ企業に制限されていますか?


26

継続的デリバリー、自動化などのDevOpsを説明するプラクティスは、SaaS製品などの継続的なサービスを提供する製品に関連しています。

たとえば、他のクライアントのためにプロジェクトを主に行うソフトウェア開発会社は、プロジェクトが終了した後、これらを維持することはありません。また、クライアントプロジェクトは無関係であるため、他のクライアントと共有されません。

DevOpsは、1回限りの複数のプロジェクトを開発する企業にも適用されますか?この場合、どんなDevOpsプラクティスが適用されますか?

回答:


32

絶対違う!

DevOpsは、より効率的にするために、従来のサイロ(部門)をすべて分解することです。

チーム間のコミュニケーションの改善、可視性の向上、信頼性の高い自動化されたプロセスは、より良い製品を実現する方法です。

以前は、大手ツール会社で働いていましたが、そこでは社内ツールをサポートし、一般向けのWebサイトを開発していました。

このケースでのDevOpsの利点は次のとおりです。

  • 継続的なビルドを通じて、コードに統合またはビルドの問題がある場合、開発チームに遅刻ではなく早めに知らせます。コミットしたばかりのコードに心を留めたまま、問題を修正できます。
  • (QAへの)継続的なテストと配信により、QAチームは問題を早期に発見し、早期に報告することができました。これにより、バグの発見と修正にかかる時間が短縮され、これらの調査の複雑さが軽減されました。
  • ログ収集および集計ツールを使用せずに、開発者が通常見ないものにアクセスできるようにしました(デバッガーに非常に熱心でした:)-ログが他のチームによってどのように表示および使用されるかを理解することで、ログの全体的な品質が向上しました
  • 多くの場合、情報を共有し、ドキュメントを作成してチーム間で知識を共有し、壁を壊そうとしました。Opsのニーズを理解することにより、アプリケーションをブートストラップするときに常に留意すべきこと(プロパティの管理/場所など)についてのガイドをいくつか作成します。開発者の現実を理解することで(より多くの機能をコーディングし、より速く、gogogogo!)、開発者のニーズにより適したサーバーとクラスターを作成することができました。
  • 展開の全体的な品質も大幅に改善されました。展開はチームによって処理されたため、OpsとDevの両方を完全に可視化できました。これにより、開発者がパッケージと1ページのドキュメントを「Install this!」と言うopsに引き渡す「コードハンドオフ」に関連する多くの問題が解消されました。

全体として、1日1回または1か月に1回実稼働環境を更新するかどうか、および所有する顧客数やビジネスモデルに関係なく、すべての企業がより良いコミュニケーション、より良いツール、より良い可視性、より速いフィードバックを使用できます、等


1
確かに、DevOpsチームでも、年間のパブリックリリースのほんの一握りを持つ大規模なembeeded製品に、実質的にすべてのSW開発組織に適用することができます-連続配信を使用して内部で彼らの開発パイプライン、彼らはまだいくつかのDevOpsチームのメリットを享受することができます:より良い品質、コスト削減、リリース予測可能性など
ダンコルニレスク

答えはSaaSを思い出させますが、SaaS以外の製品またはサービスがこれらのプラクティスからどのように利益を得ることができるかを実際には十分に説明していません。
エフゲニー

私が取り組んでいた製品はSaaSではありませんでした(まったく逆です)。しかし、理論的根拠は変わりません。SaaSであるかどうかは関係ありません。DevOpsは非伝統的な方法で製品を改善しようとします。私たちの価格設定モデルや提供物については何も知りませんでしたが、それほど大きな違いはありませんでした。
アレクサンドル

13

私のチームと私は、「一度限り」の製品を開発する責任があります。一度完成した製品は、維持費としてクライアントに提供されるか、場合によっては有料で当社が管理します。

クライアントからの一定のフィードバックを処理し、信頼性が高く、実行が実証されているものを確実に出荷するために、しっかりした開発パイプラインを維持する必要があります。

クライアントは(ほとんどの場合)DevOpsを気にしませんが、それでも役に立ちます。DevOpsを使用すると、新しいビルドを迅速にプッシュできるため、クライアントは数時間ではなく数分でフィードバックを確認でき、Jenkins / Travisを介したテストでエラー/バグをキャッチすることもできます。

プロジェクト全体で展開戦略が同じになるように、アプリケーションのコンテナ化に重点を置いています。Dockerを使用すると、アプリケーションをクライアントに簡単に渡すことができます。

DevOpsによって節約されるコストを決定するのは困難です。パイプラインに使用することを選択したソフトウェア(Travis、Jenkins、Puppet、あなたが持っているもの)の形で追加コストが発生しますが、バグを修正したり、クライアントに迅速にフィードバックすることで時間とお金を節約します。私たちの迅速な応答時間は、お客様を幸せにし、財布を幸せにします。


これが重要な理由と利点を教えてください。クライアントは実際にあなたのパイプラインを気にしていますか、それとも約束された日付に完成したプロジェクトと彼らが支払う必要がある価格を気にしますか?これらの「devops-y」をすべて行わないことでコストを削減できますか?これらのことをやらないことでプロジェクトにもっと時間を費やして、プロジェクトのためにもっとお金を得ることができますか?
エフゲニー

1
@Evgeny DevOpsは、私の回答で説明した理由により、プロジェクトを予定どおりに予算内で完了するのに役立ちます。DevOpsを削減することで、私が説明したメリットも削減できます。多くの場合、構築とテストは、予算内で予定どおりに行うのに役立ちます。後でバグを見つけるには、費用がかかり、修正に時間がかかります。それは何度も証明されています。クライアントはパイプラインを気にしませんが、フィードバックを待つ時間が長ければ長いほど、書き換えのコストと時間がかかります。
アレクサンドル

アジャイルソフトウェア開発だけではありませんか?
エフゲニー

@Evgeny私は答えを明確にするために更新しました。アジャイルを使用しますが、DevOpsのメンタリティが得られないという意味ではありません
Turtle

1
@Evgenyは、おそらく単体テストと受け入れテストを維持しないことでいくらか節約できますが、これはDevOpsアンチパターンである技術的負債を積み上げます。数週間または数か月はそれで済ませるかもしれませんが、すぐに(おそらく)テストが不可能な混乱を維持するのが難しくなります。
スティーブバトン

3

私は、ソフトウェアをシュリンクラップ製品として、完全にインストールおよびサポートされた展開として、およびデバイスに埋め込まれたコードとして、ソフトウェアを製造する企業で働いてきました。これらすべての企業で、DevOpsは開発に不可欠なサポートを提供します。

  • コンパイラ、ライブラリ、その他のビルドツールの既知の制御された構成を使用した、ソフトウェアの自動化された再現可能なビルド。
  • 回帰テストおよび新しい機能テスト用の自動化された反復可能なシステムテスト。
  • その他の自動化された定期的なアクション(たとえば、サポートされているすべての言語で利用可能な継続的に更新されるサンプルスクリーンショット、翻訳者による検証、技術者によるユーザーマニュアルへの組み込みなど)。

すべての場合において、これらは個々の開発者 1回限りでできることですが、それは開発者の時間を有効に活用できず、自動ビルドと同じ構成制御の保証もありません。


自動化はdevopsではありません。最終的に以下のデビッドボックの答えと同じコメント(申し訳ありませんが、私のコメントは、私が投票したときに失われた、ちょうどそれに気づいた)
-Tensibai

3

ソフトウェアの開発と実装に関する活動は、以前は部門間の深い統合を必要としませんでした。しかし今日では、すべての部門(開発、IT運用、品質保証など)を密接に協力する必要があります。

開発者にとって、変化は彼らが支払うものです。ビジネスには常に現代の世界に合わせた変更が必要です。この理解により、開発者は可能な限り多くの変更を作成するようになります。ITの専門家は異なる理解を持っているため、変化は有害です。彼らはそれぞれ、それが正しく機能し、ビジネスに利益をもたらすと考えています。確かに、それらを別々に考えると、両方とも正しいです。

すべての従業員は、単一のプロセスの一部であることを理解する必要があります。DevOpsは思考を養います。これにより、すべての人の個人的な決定と行動は、単一の目標の実現に向けられるべきであると認識することができます。また、成功は、個々の役割の成功からではなく、開発から配信までのサイクル全体に対して測定する必要があります。開発者とメンテナンススペシャリストの間の緊密な協力の結果、新世代のエンジニアが形成され、両方の分野の最高の成果を活用して、ユーザーの利益のためにそれらを結合します。これは、開発、構成管理、データベース管理、テスト、およびインフラストラクチャ管理の経験を持つクロスファンクショナルチームの出現に現れています。

そのため、この方法論はSaaSだけでなく有用です。


0

どういたしまして。このスレッドにはすでに素晴らしい例がありますが、私自身の逸話を共有したいと思います。2001年に、CDの作成を伴うリリースを含むソフトウェアプロジェクトを継承しました。リリースプロセスのドキュメントには、以前のエンジニアが文書化した40(!)ステップが含まれていました。このステップには、「この設定ファイルを開き、新しいリリース」。

そのビルドプロセスのすべてのステップを積極的に自動化し、そのような手書きの指示をbashでスクリプト化された「パッチ」のようなものに置き換えました。プロジェクトファイルにパッチを適用できるようにするには、サードパーティのインストールツールベンダーとチケットを開く必要さえありました。

そのプロセスが自動化されると、「CDジュークボックス」を購入しました。テストに合格すると、ビルドマシンは毎晩新しいインストールCDを自動的に作成します。テスターは翌朝に来て、ディスクをつかみ、すべてがインストール可能であることを確認できます。

ソフトウェアをサービスとして展開できる場合、フィードバックループは確実に厳しくなりますが、自動化、フィードバック、サイクルタイム、小規模リリースなどの中核的な原則はすべて適用されます。


これは、関連する自動化ですが、ないに関係私はplury規律チームのどこでも、彼らが継承する事を自動化するだけオプスについてのリファレンスを参照しない、どのような方法で組織をDevOpsチーム
Tensibai

これは2001年でした... DevOpsが登場するずっと前からです。これは単なる自動化ではなく、最終的にDevOpsの「文化」と呼ばれるようになったのとまったく同じ方法でプロジェクトの管理を合理化したと思います。そのため、SaaS組織外のDevOps態度の例です。
デビッドボック

DevOpsは自動化でもプロジェクト管理でもありません。ルートでサイロベースの組織を壊すことです。この回答が質問に本当に関係しているとは思わない(申し訳ありませんが、これはその面白くないことを意味するものではありませんが、IMOの正しい場所ではなく、実際にどこにあるのかわかりません、来るかもしれません)後で)
天柴街

CDを一貫してすばやくカットすることで、以前よりもはるかに迅速にQAからフィードバックを得ることができるようになりました。これにより、サイロが削減されました。集中化された活動予算の周りの領土を無効にするまでに1、2年かかったので、それを排除しませんでしたが、それは確かに起こるmakigの重要なステップでした。また、リリースプロセスが中断されたとき、私たちはもっと早く知りました。私は、DevOpsへの私の個人的な道として、このような多くの小さなことを信じています。
デビッドボック

この最後のコメントはこの質問の下でこの答えにもっと意味を持ちます、あなたはそれを含めるために編集する必要があります、私はまだこれがこの形式に合わないと感じますが、このプライベートベータの全体的な進化を観察するとき、私の位置は間違っているようですので、 ... それはあなた次第です。情報を編集せずに私の投票を削除することはできません
-Tensibai
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.