処分

ちょっと想像してみてください。あなたのディストリビューションに基づいたハードウェアとソフトウェアの複合体を開発していて、多くのサーバーで構成され、たくさんのロジックがあります。 許可した場合、ユーザーはあなたの頭をでません。 3つの永遠の質問が浮上します。何をすべきか？ どうするか そして誰が責任があるのでしょうか？

さらに本文では、どのようにして安定的にリリースを開始し、どのようにリリースしたかについての歴史があります。 記事を引き伸ばさないために、ユニット、手動テスト、および生産性を高めるためのすべての段階については説明しません。

最初はMVPでした

特に最終目標が正確にわからない場合は、すべてをすぐに行うことは困難です。 MVPステージでの最初の展開は次のようなものでした。

make dist for i in abc ; do scp ./result.tar.gz $i:~/ ssh $i "tar -zxvf result.tar.gz" ssh $i "make -C ~/resutl install" done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、スクリプトはCIがそうではない点まで単純化されています。 開発者のマシンから、正直に収集して表示用のテスト環境にアップロードしました。 この段階では、サーバー構成の秘密の知識が開発者の頭にあり、ドキュメントには少ししかありませんでした。

問題は、記入方法に関する秘密の知識があることです。

figak figakおよびステージング

歴史的に、teamcityはさまざまなプロジェクトで使用されていましたが、当時gitlab CIは存在していませんでした。 Teamcityは、プロジェクトのCIの基礎として選択されました。

仮想マシンを作成したら、その中で「テスト」を実行します

 make install && ./libs/run_all_tests.sh make dist make srpm rpmbuild -ba SPECS/xxx-base.spec make publish
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストは次のとおりです。

1. 半訓練された環境では、ユーティリティのセットをインストールします
2. 彼らの仕事をチェック
3. よければ-rpmを公開します
4. 半手動モードでステージングに進み、新しいバージョンをロールします

良くなった：

• 今、マスターにはチェックされたものがあります
• 環境によっては機能することがわかっています
• 赤ちゃんの間違いをキャッチ

しかし、痛みを感じますか？

• 依存関係の問題（一部のパッケージは再構築されました）
• 誰もができる限り開発環境を開発する
• 奇妙な環境でテストが追いかけている
• 配布アセンブリ、インストールのセットアップおよびテスト-3つの異なる切断されたもの

世界を少し良くする

そのようなスキームはしばらくの間存在していましたが、私たちは問題を解決し、世界をより良い場所にするためのエンジニアです。

• 配布パッケージ全体の依存関係はメタパッケージにあります
• vagrantツールを使用して仮想マシンテンプレートが作成されました
• ansibleに書き換えられたBashインストールスクリプト
• システムが全体として正しく動作することを確認するために、統合テスト用のライブラリが作成されました
• 一部のスクリプトはserverspecでカバーされています

これが許可されました：

• 開発/テスト環境を同一にする
• アプリケーションコードで展開コードを保持する
• プロセスへの新しい開発者の参加を加速する

このスキームは非常に長い間生きてきました。 許容できる時間（ビルドあたり30〜60分）のため、手動テストを行うことなく、多くのエラーをキャッチできました。 しかし、沈殿物は、カーネルが更新されたとき、または一部のパッケージがロールバックされたときに、すべてがおかしくなり、どこかで子犬が悲しみ始めました。

暑くなってきました

プレイの過程で、別の記事に引き込まれるさまざまな問題が現れました。

1. 統合テストの実行は、次のように徐々に変化し始めました。 仮想マシンのテンプレートは、パッケージの現在のバージョンよりも遅れ始めました。 半月モードで数か月間再組み立てされました。 その結果、リリースがリリースされたときに次のようになりました。
   
   
   • 自動的にvmdkになります
   • 仮想マシンにフックされたvmdk
   • 結果のVMはパックされ、s3に注がれました（ところで、s3で浮浪者の友人を作る方法を知っているのは誰ですか？）
2. マージの承認により、ビルドのステータスは表示されません-gitlab ciに移動しました。 彼らは少し血がかかりました-私は通常のタグによっていくつかのビルドのトリガーを放棄しなければなりませんでした、残りは幸せです。
3. 週に一度、リリースをリリースするためのルーチンがありました-自動化：
   
   
   • リリースバージョンの増分
   • 終了したタスクに関するリリースノートの生成
   • 変更ログの更新
   • マージリクエストの作成
   • 新しいマイルストーンを作成する
4. ビルドを高速化するために-リンター、通知、ドキュメントアセンブリ、テストの一部など、手順の一部がdockerによって実行されました。

やや単純化したため、最終的なスキームは次のようになりました（ビルド間の非自明な接続は赤でマークされています）。

1. 開発パッケージ用の多くのRPM / DEBリポジトリ
2. アーティファクト（ファームウェア、スカッシュ、ISO、VMテンプレート）を保存するためのS3ストレージ
3. 同じブランチでディストリビューションアセンブリを実行すると、結果が異なる可能性があります。 パッケージ間の依存関係はハードコードされておらず、リポジトリの状態が変わる可能性があります
4. ビルド間の多くの明白でない接続

これが許可されました：

• プライベートリリースを週に1回発行する
• 競合の数を減らし、テストの実行を増やすことにより、開発速度を向上させます

おわりに

得られた結果を理想と呼ぶことは困難ですが、その一方で、この種の問題に対する既成のソリューションは見当たりませんでした。 この作品からの主なメッセージ：

• 1000番目の方法は、最初のステップから始まります
• 痛みがあります-それを減らします。

UPD： ロシア語版