その後、彼らはすべて少し成熟しました。 Redmine / jira / etc、git / svn、jenkins、spinx-docs / rubydoc / doxygen / etc、wiki、ユニットテストが登場し、何らかの形で使用され始めました。 サブプロジェクトが登場し、スタンドが成長しました。 Servachoksの生産はいくつかになりました。 管理者は、塩/人形/などを上げて監視し、クモのように彼の巣に座って、塩のマスターの設定を規則化し、そこからstate.highstateを引き出します。
人生
しかし、これは座って（プロジェクトの）人生について少し考える良い機会です。
ライフサイクルには7つの段階しかありません。
- 概念設計。 この段階では、 何をする必要があるかを理解する必要があります。
- 建築デザイン。 この段階では、その方法を理解する必要があります。
- 実装 これは、間接的なコーディングと単体テストです。
- 検証 プログラムが目的の機能をすべて実行することの検証。
- 検証 プログラムがまだ使用できることを確認してください。 これは、前の段落から突然続くものではありません。
- 試運転。 通常、リリースの展開、データ移行、ユーザートレーニングが含まれます。
- 実際には操作自体。
- 廃止措置
八。 誰もが最後のポイントを忘れています。 しかし、それは非常に重要です（原子力発電所だけでなく）。 ソフトウェアプロジェクトの場合は、データを処理する必要があります。 試運転する前の段階で、必要なすべてのデータをそこから抽出できることを確認する必要があります。また、データが実際に抽出されたことを廃止する段階で確認する必要があります。
これは、システムエンジニアリングで採用される基本的なスキームです。 規模、業界の詳細、PMの宗教的信念に応じて、ステージの名前を変更したり、接着したり、逆に押しつぶしたりすることができますが、健全なプロセスは常にこのスキームと相関関係があります。 コマンドでアジャイルが受け入れられた場合、図は単一のストーリーのライフサイクルを説明しています。
なぜこれだけなのか。 このコンテキストでは、構成管理は製品を一貫した状態に維持するプロセスです。 それは最初の段階の完了近くのどこかで始まり、プロジェクトの死でのみ終わります。 さらに、このプロセスを怠ると、突然死に至る可能性があります。
何が壊れるか？
ライブラリバージョン。 収集し、クラス図をスケッチし、libcrutchの使用に同意しました。 1つのチームはlibcrutch-1.0に長時間座っていましたが、2番目のチームはそれを見つけてlibcrutch-2.0をインターネットからダウンロードしました。 そして、統合テストでのみ判明します。 libcrutch-1.2.14とlibcrutch-1.2.15の違いについてもバグをキャッチできます。 そして、あらゆる種類のLD_PRELOADまたはdockerは、火に燃料を追加するだけです。 プロジェクトがすべてマイクロサービス上にある場合でも、インターフェースはlibcrutchから受信したデータと交換でき、バージョンが異なるとフォーマットも異なります。
コンポーネントのバージョンが一致しません。 libbaseを見た人もいれば、libManagementFacadeを見た人もいました。 その過程で、libbase-1.14.3には小さなながらも潜んでいるバグがあることが判明しました。 私たちは話し、訂正し、忘れました。 libbase-1.14.4でテストされ、libbase-1.14.3がリリースされました。
環境構成の変更。 1つのPOSTリクエストが突然長時間動作し始めました。 nginxでバックエンドの応答を待つためのタイムアウトを増やしました。 スタンドの管理者が修正し忘れました。 彼らは展開し、再び古いバグをキャッチしましたが、現在は戦闘状態にあります。
設計決定の変更。 私たちはWindowsでそれを始め、RMSのアイデアに触発され、Ubuntuに切り替えることを決めましたが、彼らは皆にソリューションをもたらしませんでした。 彼らは収集を開始し、全員がdebパッケージを持ち込み、戦車に乗っていた誰かがexe'shnikを持ち込みました。
ユーザーにとって重要な機能の喪失。 彼らは新しいバージョンを持ち込み、長い間デザインの変更、新しいフレームワーク、高度なアルゴリズムについて話しました。 ユーザーは耳を傾け、うなずき、次のように言いました。「これはすべて順調ですが、私たちの要求に応じて型を作ってくれました。 彼女は以前、3番目のメニュー項目の5番目のサブ項目でしたが、現在はどこにいますか？」
どうする
プログラマがgitを持っていることは非常に幸運です。 彼は矢面の矢面に立ち、彼ら自身の少しを必要とします。
- プロジェクトの機能に必要なすべてのコンポーネントを定義し、それらが正しくバージョン管理されていることを確認してください。 最初の近似としての構成は、コンポーネントとそのバージョンのリストです。
- 構成がスタンドから実稼働環境にどのように転送されるかを理解します。
- 要件管理を開始します。 一般的に、要件管理は別のプロセスです。 構成管理の一部として、リリースキットに該当する各コンポーネントについて、このコンポーネントの要件とそのステータスを正確に説明するドキュメントが添付されていることを確認する必要があります：完了、未完了、一部完了、予約あり。
- とにかく、各コンポーネントには、それが何を、どのように、そしてなぜ行うかを説明するドキュメントが必要です。
概念設計の完了段階で、主題の専門家が「私たちはそのようなシステムが必要です！」と言うとき、-技術者は満場一致で「それをやろう！」と言います。システムの合意された説明が専門家の頭から取り出され、要件にカットされ、文書化されました。 開発中に、この説明は変更されます。 説明がバージョン管理されていることを確認する必要があります。 良いオプション、それがテキストの場合、gitでそれを拾います
建築設計の段階で、 建築家が彼の見方を言ったとき、あなたはこのビジョンが彼の頭から取り出され、ドキュメントに入れられ、バージョンのタグが貼り付けられていることを確認する必要があります。 これが図付きのノートブックシートの場合は、スキャンしてファイルシステム（またはwiki）に配置し、リンクを作成する必要があります。
開発段階では、コードが文書化されていることを確認する必要があります。 モジュールには、要件と動作を説明する個別のドキュメント（git内）があると便利です。 redmine / jiraに多くの情報を残すことは価値がありません。 大きな機能を完了した後、マスターにマージする前に、タスクトラッカーからの説明がドキュメントに正しく転送されることを確認する必要があります。 しばらくしてから、別のタスクの一部として、動作が変わる可能性があり、いくつかのタスクのドキュメントを収集するのは難しいでしょう。 タスクトラッカーは完全な画像を提供しません。
ユーザーマニュアルは、開発段階では適切です。 （可能であれば）gitに保存し、コードと並行して編集します。 特別なテクニカルライターがいなければ、コンテキストはなくなり、誰もが忘れてしまいます。ドキュメントは絶対にありません。
検証中に、プログラムが高度な要件を満たしているかどうかがチェックされます。 最後に、すべての要件に、達成済み/未達成のステータスが割り当てられていることを確認する必要があります。
検証段階で、プログラムを使用できるかどうかがチェックされます。 プログラムの動作に加えられたすべての変更がすぐにドキュメントに反映されるようにする必要があります。
試運転の段階で、リリースの準備とローリングの正確性がチェックされます。 正しいバージョンのすべてのコンポーネントがそこに組み込まれていることを確認する必要があります。 ここでの主な打撃は塩/人形です。 それらを使用せずに、単にインストール手順を発行するだけで可能ですが、それらを使用する方が簡単です。 それらを前もって正しく調理する必要があります。
操作フェーズについては、すべてが明確です。 製造元の指示に従うだけです。
廃止措置の段階で、必要なデータがすべて取り出されていることを確認してください。
組み立てと塩/人形について。 これは2番目の防御ライン（gitの直後）であり、アプリケーションの運用スキームは次のとおりです。
- 各サードパーティパッケージの状況が明確であることを確認してください。それがどこから来たのか、どのバージョン、どのパッチが適用されたのか。 ある種の大根（悪者）が物理的に異なるファイルに同じバージョンを貼り付ける場合、彼が間違っていると納得させるか、すべての製品に追加バージョンを貼り付ける必要があります。
- すべてのrpmが1つのリポジトリに落ちた場合、どのバージョンがロールされるかが明確であることを確認する必要があります。 リポジトリ全体の再構築スクリプトを作成して、リポジトリの全バージョンを貼り付けることをお勧めします。 もう1つの方法は、マニフェスト/ slsファイルでバージョンを明示的に示すことです。 ちなみに、パペットにはバグがあり、パッケージリソースにはダウングレードの方法がわかりません。 なぜ彼らが恥じていないのか、私にはわかりません。
- すべてのマニフェスト/ slsファイルはgitに保存されます。 塩の柱または人形のクラスパラメーターには、スタンドと生産を区別するもののみが表示されます。 たとえば、Webサービスのulrs、postgresのshared_buffersなどのパラメーター、デバッグモードを有効にするフラグなどです。 他のすべては冷酷に難しい。 パラメータはスタンドの展開中に一度設定され、将来変更されることはほとんどありません。 slsファイルはコードとして認識され、スタンドにロールされ、テストされ、そのまま本番環境に転送されます。
以上です。 構成を正しく管理します。良いプロセスとは、すべてのレーキを一巡し、初めて素晴らしい結果をもたらすプロセスであることを忘れないでください。