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

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

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

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

絶対違う！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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