その場合、継続的インテグレーション（継続的インテグレーション）、継続的検査、継続的フィードバックの長くて厄介なパス-これがあなたのパスです。 ご想像のとおり、パスも連続しています。
なぜこれをしているのですか？ （免責事項）
皆さん、カレンダーを最後に見たのは2015年で、夏は暑かったのですが、コーヒーはもう寒かったです。 そして、技術革新、アクセス可能な情報、それを行う方法に関するインターネット上の大量の資料、さらにそれを行う方法についてのこの時代では、それは必要ではありません。 そして同時に、企業を技術的負債の計り知れない穴に追い込む。
それにもかかわらず、この特定のケースでは、神や悪魔を信じないことは本当に不可能な状態で、プロジェクトは常に私の手に渡ります。 そこにあるこのような多くの欠陥、「深く」は、単に想像を絶するものです。 このようなキャンペーンのおかげで、私は常に反対しているわけではありません。 私はこのすべてを書いていますa）単に興味がない：あなたの意見を本当に知りたい、そしてb）あなたが見て、誰かを助けます。 そして、私は仕事量を減らすことをあまり心配しません。インドでは（つまり、修正する必要があるすべてのものの大部分がそこからやってくる）、彼らはHabrを読んでいるとは思いません。 時々、そこのコーダーはまったく何も読まないように思えますが、少なくとも何かがうまくいくまで、単に鍵盤をランダムに叩きます。 さて、大丈夫、会話は彼らについてではありません。
もちろん、継続的な統合またはその要素が完全な展開の真髄であると主張しているわけではありませんが、実践は良いことです。 いいよ。
簡単な数学
SEIによると、コールドフィックスの費用はコードの各行につき2.656ドルです（証明へのリンクは提供していません。すべてが簡単にグーグルで検索されます）。 欠陥は深く位置し、遠くを見て、通常は即時の機能と技術/ビジネス要件の両方に直接影響するため、通常、このようなラインは非常に多くあります。 外観にすぐに欠陥に気づき、駆除する場合、いくつかの簡単な操作、手先のたわみ、および（場合によっては）わずかな詐欺で十分な場合。 これは、必要なコードが少なく、時間と機能が大幅に削減されることを意味し、安定性とさらなる運用と保守の両方の要件を満たします。
では、なぜ継続的（統合+検査+フィードバック）=継続的な成功なのでしょうか？
誰もがよく知っているように、マネージャーとプログラマーは互いに異なっています。 後者は、緊張したペンでコードを記述し、暗記します。 そのため、マネージャーは受け取った情報（真または歪んだ情報）に基づいて製品の安定性を想定し、プログラマーはコードに欠陥がないと判断し、特定のビルドの準備ができているかどうかの疑念を排除します。
NI（継続的インテグレーション）は疑念を排除し、一定レベルの事前対策へのアクセスを提供します。 すべてのバージョン（gitブランチ）で発生する可能性のある問題は継続的に監視されるため、開発プロセスに最適なQA要素が追加されます。
継続的に正しく統合するには？
ここに書いたものはすべて、具体的な例がなければ意味がありません。 はい、そして私たちは市場で子羊の足を交渉していませんので、あなたは新鮮さのために私の言葉を取ります。
継続的インテグレーションのキーポイント：
- 多くの場合（少なくとも1日1回）、コードはリポジトリに入力されます
- 自動テストが書かれています
- プライベートビルドが実行されます（プロセスは、開発者リポジトリ、開発者リポジトリに保存されているソースコードのアセンブルで構成されます）
- 壊れたコードはストレージに入力されません
- 壊れたビルドは修復されます
- すべてのチェックとテストが検証され、壊れたコードのリポジトリからのコードが使用されていないことも検証されます
連続検査
継続的な検査は、NIの重要なコンポーネントであり、次のことを求めています：このプロセスは、開発プロセス全体を表示および視覚的に視覚化することが義務付けられているため、お金のあるアパートの鍵を握っている実権を握る大叔父には明らかです。 つまり、検査は重要で揺るぎない部分であり、次の要素に分けることができます。
1.コード分析とレポート
2.トレンド
3.最近の変更で発生したすべての欠陥を説明する収集された情報
4.主な（ビジネス用）要素に直接焦点を当てる
5.考えられるすべての問題と欠陥の完全な制御
継続的なフィードバック
ノキア-人をつなぐ！ このスローガンは有名であり、揺るぎないハンマーとハエのたたきの製造元のマーケティング担当者が当初提案したよりもはるかに多くの場合に適用できます。 私たちの特定のケースでは、継続的なフィードバックがフィンランドのツールの役割を引き受け、製品の作成に関与する全員の間に橋を架けます。
なぜ必要なのですか？ まあ、まあ、文化的なコミュニケーションは健康な社会の基礎であり、常に最新のものである顧客は満足している顧客です（不必要な愚かな質問でプロセスに参加しません）。 他の場所と同様に、主なことはすべてを正しく行うことです！ シンプルなルールに従ってください： 「適切な人々。 適切なタイミングで。 正しい形で。」 情報を正確に伝える方法-これは、次のような世紀の問題ではありません。
- SMS
- 特別なブラウザプラグイン
- メール
- はい、サイレンまたは他の人でさえ、この問題のために特別に設計された音声通知
それでは、要点を説明しましょう。 考慮すべき小さなケースを次に示します。
事例紹介
プロジェクト：ブログ機能を含むオンラインニュースポータルで、ビデオクリップを表示します（あなたが思ったことではなく、あなたに思いをiせます！）そして、コミュニティ全体を代表します。 ポータルに提供するテクノロジー：
- Drupal
- MySQL（クラスター）
- モンゴッド
- Javascript
陰謀のために、そして署名された書類の山のために、すべての名前が変更されており、現実との類似性は純粋にランダムです（まあ、またはまったくランダムではありません）。 これが私の目の前に最初に現れた写真です。
心配しないでください、これは難しいことですが、モニターに聖水をまき散らしたいという欲求を克服しようとしてください。すべて準備ができています。
だから、私が来た結論：
アーキテクチャが明らかに曲がっており、一連のボトネクが作成され、システム内での効率的な配布ができず、メンテナンス段階で大きな頭痛の種になりました。 一般に、すべてがあまり修復可能ではありません。 このコードは基準を満たしておらず、それらの負債は1年半（1年半）にも及ぶ！
引き受けたもの：
- アーキテクチャの再構築
- コードの再構築
- プラットフォームホスティング
- 強力な（非常に）外部キャッシュ
どうしたの？
私自身のように、あなた自身のために判断してください-甘いもの。 少なくとも、それが何であったかと比較して。 とにかく、プラスで5で働く：
- 10,000,000レコードのデータベース
- 1秒あたり10,000メッセージ
- このサイトはYahooのメインページで繰り返し輝いています
- 1時間あたり10 + Kユーザー
おわりに
あなた自身がNIの助けを借りて良い仕事の結果を見ました。 多くの外部プロジェクトを開発している人々の間で、なぜこの方法論が依然としてあまりにも貧弱なのですか？ 産業としてのアウトソーシングを破壊し、通常の専門家への信頼を損ないます。 そして、はい、あなたはスプーンとフォークで食べることができることを知っています、そして他の解決策もあります。 しかし、なぜ車輪を再発明するのでしょうか？ だから教えてください、もしそうなら、あなたはNIを使用しますか？