タグ付けされた質問 「continuous-integration」

ソフトウェアエンジニアリングでは、継続的インテグレーション（CI）により、ソフトウェア製品全体の継続的な構築と自動テストが頻繁に実行されます。少なくとも1日に1回、多くの場合1日に数回、時にはバージョン管理システムにチェックインするたびに頻繁に。

23
ナイトリービルドが壊れたときに謝る方法[終了]
私のプロジェクトで最初にコミットした結果、ナイトリービルドが壊れてしまい、リリースが近づいているので人々は私を取り囲んでいます。私は誠実に聞こえると同時に、これが私の最初のコミットであり、これがこれ以上繰り返されないことをほのめかす謝罪メールを送信したいと思います。 英語が母国語ではないので、正しい単語を見つけるのに苦労しています。誰か助けてくれますか？
9
CIサーバーで単体テストを実行する意味は何ですか？
CIサーバーで単体テストを実行するのはなぜですか？ 確かに、何かがマスターにコミットされる頃には、開発者はすでにすべての単体テストを実行し、新しいコードで発生した可能性のあるエラーを修正しています。それは単体テストのポイントではありませんか？そうでなければ、彼らは壊れたコードをコミットしたばかりです。
13
分岐するかしないか？
最近まで、私の開発ワークフローは次のとおりでした。 製品所有者から機能を入手する ブランチを作成します（機能が1日以上の場合） ブランチに実装する メインブランチからブランチへの変更をマージします（後方マージ中の競合を減らすため） ブランチをメインブランチにマージする マージに問題があることもありましたが、一般的には気に入っています。 しかし、最近、継続的な統合や継続的な配信などを実践するのが難しくなるため、ブランチを作成しないというアイデアの信者が増えています。 Git、Mercurialなど 質問は、最近のブランチを使用する必要がありますか？
7
期限付きのTODOコメント？
バックグラウンド 私は、ゼロダウンタイム展開の実装を検討しているチームで働いています。これを実現するために、ブルー/グリーン展開戦略の使用を計画しています。研究を行う上で私が理解していることの1つは、データベースの変更を行うことがどれほど複雑になるかです。カラムの名前を変更するなどの簡単な操作は、完了するまで3回の完全なリリースサイクルを必要とします。 変更の完全なロールアウトに複数のリリースサイクルがかかると、ヒューマンエラーが発生する可能性が大きくなるように思えます。リンクされた記事では、2つのリリースにはコードの変更が必要であり、3つのリリースにはデータベースの移行が必要であることを示しています。 私が探しているもの 現在、何かを行うことを覚えている場合は、問題管理システムでチケットを作成できます。または、TODOコメントを作成することもできますが、おそらく完全に忘れられます。 私が探しているのは、TODOコメントに期限があり、この期限が切れた場合、継続的インテグレーションシステム（現在使用する未定）がビルドを拒否する方法です。 たとえば、列の名前を変更する場合、最初の移行を作成し、次に2つのTODOコメントを作成して、残りの2つの移行が作成されるようにします。 // TODO by v55: Create migration to move constraints to new column, remove references to old column in app // TODO by v56: Create migration to drop old column これは実装するのはかなり簡単に思えますが、車輪の再発明をしたくないので、このようなものがすでに存在するかどうか疑問に思っています。 追加の考え ローリングデプロイメントとブルー/グリーンデプロイメントがベストプラクティスであると考えられるため、ここでXYの問題に苦しんでいるように感じます。データベースの更新の痛みを軽減するソリューションを見つけることができないのは奇妙に思えます。私が間違っていることを完全に調査していると思われる場合は、コメントでお知らせください！とはいえ、私が挙げたデータベースの例はほんの一例に過ぎず、期日付きのTODOコメントは他の状況でも役立つと思うので、この特定の状況に近づいていたとしても、私は本当に自分の答えにしたい実際の質問も。ありがとう！ 編集：これが役立つ別の状況を考えました。機能のトグルを使用して、準備ができたときにアプリの一部を有効にする場合、それらをクリーンアップするように注意する必要があります。そうしないと、Toggle Debtになる可能性があります。期限付きのコメントは、これを思い出す良い方法です。
9
複数のクライアントに対して同じソフトウェアの異なるカスタマイズされたバージョンを維持する方法
ニーズの異なる複数のクライアントがあります。ソフトウェアはある程度モジュール化されていますが、すべてのモジュールのビジネスロジックをあちこちで調整する必要があることはほぼ確実です。モジュールごとにクライアントを個別の（物理）モジュールに分割することを正当化するには、おそらく変更が小さすぎるため、ビルドの問題、リンクの混乱を恐れます。しかし、これらの変更は大きすぎて、構成ファイルのスイッチで構成するには多すぎます。これは、展開中に問題を引き起こし、特にティンカータイプの管理者では多くのサポートトラブルを引き起こす可能性があるためです。 ビルドシステムに、クライアントごとに1つずつ、複数のビルドを作成させて、問題の単一の物理モジュールの特殊バージョンに変更が含まれるようにします。だから私はいくつか質問があります： ビルドシステムに複数のビルドを作成させることをお勧めしますか？ソース管理、特にsvnにさまざまなカスタマイズを保存するにはどうすればよいですか？
9
CI主導の開発をどのように回避しますか...？
私は非常に大規模な研究主導型のオープンソースプロジェクトに取り組んでおり、他の多くの定期的な貢献者もいます。プロジェクトは現在非常に大きいため、コンソーシアム（2人の常勤従業員と少数のメンバーで構成される）がプロジェクトの維持、継続的統合（CI）などを担当しています。外部の統合のための時間がありません。しかし貢献。 このプロジェクトは、「コア」フレームワーク、約50万行程度のコード行、コンソーシアムが管理する「プラグイン」の束、およびいくつかの外部プラグインで構成されています。気づいてさえいません。 現在、私たちのCIはコアとメンテナンスされたプラグインを構築しています。 私たちが直面している大きな問題の1つは、ほとんどの貢献者（および特に臨時の貢献者）がメンテナンスされたプラグインの90％を構築していないことです。 GitHubでプルリクエストを行う前に、コードがマシンでコンパイルされることを確認しました。 コードは機能し、満足し、CIはビルドを終了し、問題が始まります。コンソーシアムが管理しているプラ​​グインでコンパイルが失敗しました。コントリビューターは自分のマシンではビルドしませんでした。 そのプラグインは、たとえばCUDAなどのサードパーティライブラリに依存している可能性があり、ユーザーは壊れたプラグインをコンパイルしたくない、ハードウェア上の理由でコンパイルできない、または単にできない。 そのため、PRはマージされないPRの辺りにとどまるか、寄稿者が壊れたプラグインのソースで名前を変更した変数を把握し、コードを変更し、ブランチをプッシュし、 CIがコンパイルを終了し、通常はエラーが増え、CIが満足するまでプロセスを繰り返します-または、コンソーシアムで既にオーバーブッキングされている2人のパーマネントのうちの1人が手を差し伸べ、マシンのPRを修正しようとします。 これらのオプションはいずれも実行可能ではありませんが、どのように異なる方法を実行するのかわかりません。プロジェクトの同様の状況に直面したことがありますか？もしそうなら、この問題をどのように処理しましたか？ここに表示されていない解決策はありますか？
16
プログラマーは、他の誰かの失敗したビルドを修正する必要がありますか？[閉まっている]
あるプログラマーはSVNリポジトリーにいくつかの作業をコミットしてから帰宅しました。彼が去った後、ハドソンの自動ビルドは失敗しました。別のプログラマーはこれを見て、コードの変更を調べた後、問題が1つのライブラリーがないことを検出しました。彼はこのライブラリをSVNに追加し、次のビルドが正常に完了しました。 2番目のプログラマーは正しいことをしましたか、それとも最初のプログラマーが問題を解決するまで待つべきでしたか？
8
ビルドに失敗したコミットを自動的に元に戻す
私の同僚は、ビルドに失敗したコミットを元に戻すためにCIサーバーを作成することを考えていると言ったので、（少なくともビルドを渡す場合のようHEADにmaster）常に安定しています。 これはベストプラクティスmasterですか、それとも開発者が修正するまで壊れたままにしておくよりも問題がある可能性がありますか？ 私の考えでは、コミットを元に戻すと、コミットと修正を読み直すタスクがより複雑になります（開発者は元に戻して修正をコミットする必要がありますが、これも混乱しますgit log）。修正。master安定していることにはいくつかの利点がありますが、失敗したコミットを元に戻すことは私を納得させません。 編集：それがmaster他の開発ブランチであるかどうかは関係ありませんが、質問は同じままです：ビルドに失敗したコミットをCIシステムが元に戻す必要がありますか？ 別の（長い）編集：わかりgitました、奇妙な方法で使用しています。ブランチにコミットすると他の開発者とその変更から隔離され、ブランチを再統合して競合の可能性に対処する必要があるため、ブランチの概念は実際のCIに反すると信じています。全員がmasterこの競合にコミットすると、最小限に抑えられ、すべてのコミットがすべてのテストに合格します。 もちろん、これにより、安定性のみをプッシュする（またはビルドを中断する）ことを強制し、後方互換性を壊さないように、または新しい機能を導入するときに機能を切り替えないように、より慎重にプログラムします。 CIをこのように、またはそのように行う場合、トレードオフがありますが、それは質問の範囲外です（これに関する関連する質問を参照）。ご希望であれば、質問を言い換えることができます。開発者の小さなチームが機能ブランチで協力しています。1人の開発者がそのブランチのビルドを中断する何かをコミットした場合、CIシステムはコミットを元に戻すべきですか？
9
バージョン管理フックで単体テストを実行するのは良い習慣ですか？
技術的な観点から、特定のコミットをリモートのデフォルトブランチにマージする前に、ユニットテストを実行する事前/事後プッシュフックを追加することができます。 私の質問は-ビルドパイプラインでユニットテストを保持する（つまり、破損したコミットをレポに導入する）方が良いのか、それとも「悪い」コミットが発生しないようにする方が良いのかです。 私は、この2つのオプションに制限されていないことを理解しています。たとえば、マージコミットをレポジトリにプッシュする前に、すべてのコミットの分岐とテストを許可できます。しかし、この2つのソリューションを正確に選択する必要がある場合、どちらを選択しますか。
2
build.numberがセマンティックバージョニングの「乱用」なのはなぜですか？
提案されたビルドシステム（Gradle / Artifactory / Jenkins / Chef）をシニアアーキテクトの1人に説明していましたが、彼は私に同意しませんでしたが、実際に計量するのに十分な経験はありませんでした。 このプロジェクトは、他のチームが再利用するアーティファクトとしてJavaライブラリ（JAR）を構築します。バージョン管理には、次のセマンティックアプローチを使用します。 <major>.<minor>.<patch> どこにpatchバグ/緊急フィックスを示し、minor下位互換性リリースを示しており、majorいずれかのAPIの大規模なリファクタリングおよび/または互換性のない変更を示します。 ここでの配信に関しては、私が望むものです。開発者がコードをコミットします。これにより、QA / TEST環境へのビルドがトリガーされます。一部のテストは実行されます（一部は自動化され、一部は手動）。すべてのテストに合格すると、プロダクションビルドがJARを社内リポジトリに公開します。この時点までに、JARは適切にバージョン管理される必要があり、build.numberCIツールによって自動的に生成および提供されるものを使用して、パッチ番号として機能させることを考えていました。 したがって、バージョン管理は実際には次のようになります。 <major>.<minor>.<build.number> ここでも、build.numberCIツールによって提供される場所。 アーキテクトはこれを却下し、CIビルド番号の使用はセマンティックバージョニングの「乱用」であると述べました。 私の質問は次のとおりです。これは正しいですか？もしそうでなければ、なぜですか？
12
DVCSは継続的な統合を妨げますか？
10人のアジャイル開発者のチームがあるとします。毎日、彼らはボードからタスクを選び、そのタスクに対していくつかの変更をコミットします（1日の終わりまでに）。すべての開発者は、トランクに対して直接チェックインします（Googleスタイル、すべてのコミットはリリース候補であり、機能の切り替えなどを使用します）。 SVNのような集中型CVSを使用している場合、1人がコミットするたびに、ビルドサーバーは変更を統合し、他の9人の開発者の作業に対してテストします。ビルドサーバーはほぼ1日中継続的に実行されます。 しかし、gitのようなDCVSを使用している場合、開発者はタスクを完了するまで待ってから、ローカルコミットをすべて中央リポジトリにプッシュすることができます。それらの変更は、一日の終わりまで統合されません。 このシナリオでは、SVNチームはより頻繁に継続的に統合し、gitチームよりもはるかに迅速に統合の問題を発見しています。 これは、DVCSが従来の集中型ツールよりも継続的なチームに適していないということですか？この遅延プッシュの問題をどのように回避しますか？
12
継続的インテグレーションの前に何人の開発者が私たちにとって効果的ですか？
継続的な統合に関連するオーバーヘッドがあります。たとえば、セットアップ、再トレーニング、認識アクティビティ、データの問題であることが判明した「バグ」を修正するための停止、懸念事項のプログラミングスタイルの強制などです。 継続的インテグレーションは、どの時点でそれ自体に費用がかかりますか？ 編集：これらは私の発見でした セットアップは、VSSまたはTFSから読み取り、Nantを備えたCruiseControl.Netでした。 失敗のいくつかの理由を以下に示しますが、これらはセットアップとは関係ありません。 調査コスト：赤信号の原因がコード、データ品質、またはインフラストラクチャの問題（ネットワークの問題、ソース管理からのタイムアウトの読み取り、サードパーティサーバーなど）の真の論理的不整合によるものかどうかの調査にかかった時間ダウンなど） インフラストラクチャに対する政治的コスト：テスト実行の各メソッドに対して「インフラストラクチャ」チェックを実行することを検討しました。ビルドサーバーを交換する以外、タイムアウトの解決策はありませんでした。赤テープが邪魔になり、サーバーの交換はありませんでした。 単体テストの修正コスト：データ品質の問題が原因の赤信号は、誤って記述された単体テストの指標になる可能性があります。そのため、データに依存する単体テストは書き直され、不良データによる赤信号の可能性を減らしました。多くの場合、ユニットテストを正確に実行できるように、必要なデータがテスト環境に挿入されました。データをより堅牢にすると、このデータに依存している場合、テストはより堅牢になります。もちろん、これはうまくいきました！ カバレッジコスト、つまり、既存のコードの単体テストの記述：単体テストカバレッジの問題がありました。単体テストのないメソッドが何千もありました。そのため、それらを作成するにはかなりの工数が必要になります。これはビジネスケースを提供するには難しすぎるため、今後、新しいパブリックメソッドにはユニットテストを使用することにしました。単体テストを行わなかったものは、「潜在的に赤外線」と呼ばれました。ここで重要な点は、静的メソッドは、特定の静的メソッドがどのように失敗したかを一意に判断する方法の重要なポイントであったということです。 オーダーメイドのリリースのコスト：Nantスクリプトはこれまでのところのみです。たとえば、EPiServer、CMS、またはUI指向のデータベース展開用のCMS依存ビルドにはあまり役立ちません。 これらは、1時間ごとのテスト実行と夜間のQAビルドのためにビルドサーバーで発生した問題の種類です。ビルドマスターはリリース時にこれらのタスクを手動で実行できるため、特にワンマンバンドと小さなビルドでこれらが不要であることを楽しませます。したがって、シングルステップビルドは、私の経験ではCIの使用を正当化するものではありません。より複雑なマルチステップビルドについてはどうですか？これらは、特にNantスクリプトなしでは、構築するのが面倒です。したがって、作成したとしても、これらはもはや成功しませんでした。赤信号の問題を修正するコストは、利益を上回りました。最終的に、開発者は興味を失い、赤信号の妥当性を疑問視しました。 公平に試してみましたが、CIは高価であり、単に仕事を終わらせるのではなく、周辺で多くの作業をしていると思います。アラームシステムを導入および保守するよりも、大規模なプロジェクトを大量に作成しない経験豊富な開発者を採用する方が、費用対効果が高くなります。 これらの開発者が去っても、これは事実です。優れた開発者が辞めるかどうかは問題ではありません。彼が従うプロセスにより、要件仕様、設計仕様を記述し、コーディングガイドラインに準拠し、コードが読みやすくなるようにコメントすることが保証されます。これはすべて見直されます。これが発生していない場合、彼のチームリーダーは仕事をしていません。これは、マネージャーなどが引き受ける必要があります。 CIが機能するためには、単体テストを作成し、完全なカバレッジを維持し、大規模なシステムの機能するインフラストラクチャを確保するだけでは不十分です。 結論：リリース前にできるだけ多くのバグを修正することがビジネスの観点からも望ましいかどうか疑問に思うかもしれません。CIには、顧客がUATで特定できる少数のバグをキャプチャするための多くの作業が含まれます。または、保証期間が期限切れになった場合、クライアントサービス契約の一部として会社が修正の支払いを受けることができます。
11
継続的インテグレーションを行うときにコードレビューを行うタイミング
継続的インテグレーション環境に切り替えようとしていますが、コードレビューをいつ行うべきかはわかりません。継続的インテグレーションについて読んだことから、1日に何度もコードをチェックインしようとしているはずです。これは、まだ完全ではない機能を意味していると思います。 質問は、コードレビューをいつ行うかです。 コードをチェックインする前にそれを行うことはできません。1日あたり複数のチェックインは言うまでもなく、毎日のチェックインを実行できないプロセスが遅くなるためです。 また、チェックインしているコードがコンパイルされるだけで機能が完全ではない場合、ほとんどのコードレビューは機能の完成時に最もよく行われるため、コードレビューを行うことは無意味です。これは、機能が完了したときにコードレビューを行う必要があることを意味しますが、その未レビューのコードはリポジトリに入りますか？
3
継続的インテグレーションの簡単な説明
継続的インテグレーションをどのように定義し、CIサーバーにはどのような特定のコンポーネントが含まれますか？ マーケティング部門の誰かに継続的インテグレーションとは何かを説明したいと思います。彼らはソース管理を理解しています-つまり、Subversionを使用しています。しかし、私は彼らにCIが何であるかを適切に説明したいと思います。ウィキペディアの記事は、それを適切に定義することはありません、Martin Fowler氏の記事は、のみ基本的に「統合」のあいまいな説明に続いてトートロジーである、次のようになります： 継続的インテグレーションは、チームのメンバーが頻繁に作業を統合するソフトウェア開発プラクティスです。通常、各ユーザーは少なくとも毎日統合し、1日に複数の統合を行います。統合エラーを可能な限り迅速に検出するために、各統合は自動ビルド（テストを含む）によって検証されます。 更新：私は彼らにこの画像を送った、私はより簡単なものを見つけることができなかった。 更新2：マーケティングチャップからフィードバック（質問が3つあったとき）： 私は実際には3つの回答すべてが好きです。理由はさまざまです。それらすべてに感謝するためだけにログインしたい気がします！ 明らかに彼はできません-だから彼に代わってありがとう:) 更新3：ウィキペディアの記事を見て、見出しだけを取り上げると非常に良いリストである原則が含まれていることに気付きました。 コードリポジトリを維持する ビルドを自動化する ビルドを自己テストする 誰もが毎日ベースラインにコミットします （ベースラインへの）すべてのコミットを構築する必要があります ビルドを高速に保つ 実稼働環境のクローンでテストする 最新の成果物を簡単に入手できるようにする 誰でも最新のビルドの結果を見ることができます 展開を自動化する
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.