前回の投稿では、行商人をbuildbotに紹介したかったのです。 しかし、このトピックは私には完全には開示されていませんでした。
今日は少し追いつこうと思います。
なんで？
大規模で複雑なプロジェクトがある場合、ほとんどの場合、すぐに使用できる継続的インテグレーションのシステムでは、必要なものが得られません。 そして、ここで誰もができる限り外に出ます。誰かがプラグインを書き、誰かが松葉杖を作ります。 そして、悲しいかな、2番目のオプションは非常に一般的です。 これは、選択したCIシステムに十分な柔軟性がないという事実による可能性があります。
buildbotから得られるもの
- ビルド構成でのPythonのすべての表現力
- 構成にはコードがあるため、gitに配置できます
- さて、あなたはコードをギスに固定し、コードをレビューすることができます
- 組立スケジュール関連の打ち上げ
- 最新のすべてのVCSをサポート
- あなたが望む方法ですべてを行うことができます。
- Json API
そして、欠点は何ですか？
- きれいなボタンはありません（まだ）
- セットアップは簡単です
- ドキュメントはまあまあです
- ロシア語圏のコミュニティはほとんどありません
- 自分で書くこと
例
私たちはテーブルの先頭に柔軟性を置いているので、これの視覚的な証拠を見るといいでしょう。
アセンブリを生成します
プロジェクトが異なるプラットフォームを使用している場合、アセンブリごとに新しい構成を作成するのは面倒です。
それから、数行の入力パラメーターから必要なアセンブリの数を生成できます。
これは、CyanogenModの以前のバージョンのアセンブリが生成された方法です
自己更新
マスターサーバーのすべての構成をgitに入れ、buildbotに自分自身を更新するよう指示することをお勧めします。
そうすれば、特に会社でコードレビューを実施している場合は、誤って何かを壊す可能性が低くなります。
これは、おおよそ次のスキームに従って行われます。
- マスターの隣に新しいスレーブを置きます
- ビルダーを作成し、構成が存在するリポジトリを監視するように彼に指示します
- リポジトリに新しいものが表示された場合、変更を削除してウィザードを再構成します
ここでそのような計画の実装を見ることができます 。
分割して征服する
私の意見では、すべてのアセンブリの構成を1つのファイルに保存するのは非常に不便です。 しかし、毎回、マスター構成の編集に入り、新しいインポートを追加することも喜びをもたらしません。
私自身、 このようなブートローダーの実装を個人的にここに書きました 。これは特定のフォルダーから設定を自動的に取得します。
おわりに
おそらく、これはbuildbotに興味を持つには十分ではありません。 そのことから、プロジェクトのWebサイトにアクセスして、 成功事例のリストを参照することを強くお勧めします。
そして、何らかの理由で現在の継続的インテグレーションのシステムがあなたに合わない場合、buildbotに注意を払うことをお勧めします。 私にとっては価値があります。
ご質問にお答えします。