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

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

13
バージョン管理と継続的インテグレーションを使用しない深刻な企業はありますか?どうして?
私の同僚は、継続的な統合を備えたビルドサーバーとバージョン管理ソフトウェアの両方を使用していたため、ソフトウェア部門は非常に高度であるという印象を受けていました。これは私の観点とは一致しませんでした。深刻なソフトウェアを製造していて、どちらも持っていなかった会社を知っているからです。しかし、私の経験はほんの一握りの会社に限られています。 ソフトウェア業界に属し、これらのツールを使用しない実在の会社(プログラマー3人以上)を知っていますか?そのような会社が存在する場合、そうしない理由はありますか?

6
スクラムと継続的インテグレーションによるソフトウェア開発のための優れたワークフロー
私は、スクラム方式を使用したソフトウェア開発会社において、継続的インテグレーションワークフローがどのように適合するかをよりよく理解するためのアプローチを研究しています。 私はこのようなことを考えています: それは素晴らしいワークフローでしょうか?

2
重い企業通信、構成管理およびテスト要件を備えたMercurialリポジトリ構造
私は、分散バージョン管理のタオで自分自身を再教育するのに苦労している別のSubversionユーザーです。 Subversionを使用するとき、私はプロジェクトマイナーアプローチの大ファンであり、以前の雇用主のほとんどと一緒にリポジトリブランチを構築しました。次のようなタグとトランク: branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk 実際のソースツリー内では、次のような構造(のようなもの)を使用します。 (src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | +-utilities +-libraries-+ | …

2
失敗したテストをどこにプッシュしますか?
GitHubリポジトリのブランチ設定を変更したばかりなので、[次の]ブランチではプルリクエストでCIビルドを渡す必要があります。 テストの失敗について、多くのチームメンバーとの議論が続きました。 コンテキストのために... リポジトリには、リリースがあるときにのみPRされる[master]ブランチがあるため、[master]には、メジャー、マイナー、ホットフィックス、ベータ、アルファ/アルファに関係なく、最後のリリース時点のコードが含まれます。プレリリースビルド。 [次の]ブランチは「デフォルト」ブランチで、「リリース準備完了」コードを保持するつもりです。技術的には、そのブランチはいつでも[マスター]にPRされ、リリースされます。 個々のフォークには独自の開発ブランチがあり、貢献者は[次へ] PRを行います。 自明ではないPRをレビューするとき、貢献者のdevブランチを「レビュー」ブランチにマージし、すぐに修正できるものを見つけたら、変更と新しい(時々失敗する)テストをコミット/プッシュし、PR貢献者の開発ブランチに戻ります。彼らが私の変更をマージするとき、新しい失敗したテストをパスさせてプッシュし、それらのPRが同期します。それからPRを[次へ]にマージします。 しかし、この質問はテストに合格することではなく、失敗するテストに関するものです。 テストに失敗すると、修正する必要があるものが文書化されます。 既知のバグにはテストが記述されている必要があります。これにより、何が機能していないかがわかります。 技術的には、GitHubの問題リスト(バグやクリティカル ラベルに対してフィルター処理されています)も同様です。バグを文書化するために多数の失敗したテストを用意することは良い習慣ですか? [次へ]上の障害のビルドは、私たちがリリースする準備ができていないという意味では...しかし、その後、「リリース用であることは、」ビット子供を持って「準備ができている」のようなものでしょう-あなたは決してならない、非常にこのための準備ができて、何か、どこかで(変数の重要性が)リリースで必然的にうまくいかないでしょう。 したがって、合格したテストを[次へ]にプッシュするだけです。失敗したテストをどこにプッシュしますか?つまり、PR /レビュープロセスの外ですか? たとえば、ユーザーが問題リストに新しいバグを報告し、失敗したテストスイートを作成したい-何をする必要があるか、どこで行うかを指定して、新しい貢献者がピックアップしやすくする最終的にはPRを修正します。 これらの失敗したテストをどこにプッシュすればよいですか?または、失敗したテストをどこかにプッシュすることをお勧めしますか?

6
「自動ビルド」とはどういう意味ですか?
プロジェクトに継続的インテグレーションを追加しようとしています。 ウィキペディアによると、CIの主要な部分の1つは自動ビルドです。ただし、CIとビルド自動化の記事が一致していないように見えるため、正確に何を意味するのかについて混乱しています。 特定の混乱点:「自動ビルド」とは次のコンテキストで何を意味するか PythonやPerlなどのインタープリター言語を使用するプロジェクトですか? エンドユーザーのマシンのソースからビルドしますか? ユーザーのマシンにローカルなRDBMS内のデータベースなど、単純にプリコンパイルおよび配布できない依存関係を持つアプリケーションですか?

6
自動ビルドシステムのセットアップを担当するのは誰ですか?
私は会社のプロジェクトマネージャーです。私は、CVSとして知られる標準のよく知られたバージョン管理システムを使用して、いくつかの開発者チームと協力しています。継続的な統合と自動化されたビルドを実装して、ビルドの破損や運用サーバーへの不正な展開の問題を防ぐことができるようにしたいと思います。 私は自分でこれを設定できると確信していますが、次の2つの理由でこれを自分で行いたくありません。 時間がありません。私には、マーケティング、開発に参加していないチームメンバーとのその他の利害関係者とのコミュニケーション、顧客とのコミュニケーション、プロジェクト計画などの責任があります。 最も重要なことは、私はプロジェクトマネージャーです。私の目的は、開発チームを細かく管理することではなく、リーダーシップを提供することです。 開発チームでこれをセットアップすることに情熱を持っている人を見つけるためにできることは何ですか?Java、Spring、およびGoogle App Engineの知識が必要であることを考慮して、開発者はこのタスクに適していますか?変化が懸念される変化を促進するためのヒントは何ですか?

8
「合格/破損ビルド」インジケータの代替手段
コミットごとにテストを実行する継続的な統合を行う場合、一般的なベストプラクティスは、すべてのテストを常にパスすることです(「ビルドを中断しないでください」)。 私はそれに関するいくつかの問題を見つけます: たとえば、チケットに対応するテストを作成して、オープンソースプロジェクトを支援することはできません。失敗したテストを含むオープンソースプロジェクトにプルリクエストを提案した場合、ビルドは失敗としてマークされ、プロジェクトは「ビルドを壊す」ためリポジトリにマージされたくないでしょう。 そして、レポでテストに失敗するのは悪いことではないと思います。それは、トラッカーに未解決の問題があるようなものです。これらは修正されるのを待っているものです。 同じことが会社にも言えます。TDDを使用している場合、テストを作成し、コミットしてから、テストを満たすロジックコードを作成することはできません。つまり、ラップトップで4〜5個のテストを書いた場合、休日に行く前にテストをコミットすることはできません。誰も私の仕事を取り戻すことはできません。たとえばメールで送信する場合を除き、同僚と「共有」することさえできません。また、テストの作成者とモデルの作成者との作業も妨げられます。 言うまでもなく、私はビルドプロセスを誤用/誤解しているか、継続的な統合を行っていますか?「通過する」/「通過しない」という指標は狭すぎるように思えます。 継続的な統合とTDD互換性を実現する方法はありますか? 「新しいテスト」(失敗する可能性がある)と「回帰テスト」(以前は機能していたため失敗するべきではない)を区別するための標準的なソリューション/プラクティスがあるかもしれません。


2
継続的統合ツールを選択するにはどうすればよいですか?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 5年前に閉鎖されました。 ウィキペディアで統合サーバーのこのクールな比較表を見つけましたが、ツールを自分のニーズや興味に対してランク付けする方法が少し不確かです。チャート自体には、不明とマークされたボックスが多数あるようです。したがって、Wikipediaでチャートを更新することに満足しているなら、それも素晴らしいかもしれません。 最高のパフォーマンスを発揮する製品がいくつかあるので、4つまたは5つのオプションにすばやく絞り込むことができますか? 最大のユーザーコミュニティを持ち、現在進行中の機能強化と新しいツールとの統合が最も進んでいる製品はどれですか? オープンソースの提供は最高ですか、それとも自宅の一人のユーザーにとって大いに役立つ高品質のツールがありますか? 複数のシステム(プライマリデスクトップ、ローカルのみのホームネットワークサーバー、個人用および職場のノートブック、すべてに分散した複数の仮想マシン)を使用すると問題が発生し、それらをどのように管理できますか?

5
コーディング統合は継続的インテグレーションサーバーによって実施されるべきですか?
コーディング標準/スタイルは、静的分析ツール(例:PMD、StyleCop / FxCop)を実行し、標準に従っていない場合はビルドに失敗する継続的統合サーバーによって実施されるべきですか?ビルドを失敗させるためにどの種類のルールを使用すべきではありませんか?

3
マルチリポジトリ環境でのパッケージおよびバージョン戦略
私たちは、独自のgitリポジトリを管理する複数のチームを持つ小規模企業です。これはWebプラットフォームであり、各チームの成果物は夜間テストのために1日の終わりに展開されます。バージョン管理とパッケージングに関するプロセスを形式化しようとしています。 すべてのチームには、日々の開発を行うマスターブランチがあります。各チームの品質保証メンバーは、チームの変更による成果物を、すべてのコンポーネントがシェフによって結合されるテストベッドに展開することを望んでいます。アーティファクトはtarballですが、それらをRPMに変換して、バージョンについて正しく考え、推論できるようにします。 リリースプロセスには、各gitリポジトリの開発ブランチ(ほとんどの場合マスター)からリリースブランチを切り離すことが含まれます。これは、成果物のセットでテストとサインオフを実行する品質保証に与えられます。 たとえば、これは関連するリリースブランチを持つ典型的なgitリポジトリです。 0-0-0-0-0-0-0-0-0-0 (master) | | 0 0 (rel-1) | 0 (rel-2) 開発ブランチから来るパッケージのバージョン管理を実行するスキームを見つけようとして立ち往生しています。各リポジトリのmasterブランチに過度にタグを付けたり、タグをリリースブランチのみに制限したりするのは望ましくありません。ただし、標準のyum / rpmセマンティクスを使用して、テストマシンにデプロイされたパッケージを照会できる必要があります。masterブランチにタグがない場合、開発バージョンはどのようになりますか?私git describeはビルドバージョンの有用な表現を提供できることを理解していますが、ブランチ上のさまざまなリリースポイントがタグ付けされている場合はうまく機能します。 EDIT1:@ Urban48の回答に応えて リリースプロセスについてもう少し説明する必要があると考えました。この議論のためにmaster、すべてのリポジトリにブランチがあると仮定しましょう。このmasterブランチは開発ブランチと見なされ、CI-CD対応の自動化されたQA環境に展開されます。これは、マスターの安定性を確保するために夜間テストのサブセットが実行される場所です。リリースブランチをカットする前に、このジョブのパイプラインを確認します。リリースブランチは短命です。リリースブランチを(安定したマスターから)カットした後、完全なリグレッションが実行され、修正が行われ、運用環境に展開されたとします。これには約1週間かかります。ほぼ2週間ごとに実稼働環境にリリースします。 機能ブランチは常にマスターから切り離され、CI-CD安定性チェックを受けるマスターとマージする前に、ある程度の開発者テストを受けます。 修正プログラムは(リリースブランチからカットされた)修正プログラムブランチで作成され、本番環境への影響を最小限に抑えて展開されます。 リリースおよびホットフィックスブランチのバージョン管理戦略は、semverに従います。QAサイクル中のリリースブランチはv2.0.0-rc1、v2.0.0-rc2などのバージョンを通過し、最終的にQAサインオフがになりv2.0.0ます。 バージョンがになるリリースブランチ(およびマスター)にマージされる小さな機能のドットリリースを行うことがありますv2.1.0。また、ホットフィックスはv2.1.1パターンを想定しています。 ただし、問題はこれらのブランチをバージョン管理することではありません。このバージョン管理スキームをまったく変更しないことをお勧めします。唯一の変更点は、開発ブランチ、つまり 主人。CI-CD環境で、以前のリリースから実稼働環境に存在するバージョンを確実に示す方法を教えてください。これは、理想的にはスマートgitタグ付けによって行われますが、masterブランチに過度にタグ付けしないものが推奨されます。

5
奇妙な会社のリリースサイクル:分散ソース管理に行きますか?
この長い投稿については申し訳ありませんが、価値があると思います。 私は小さな.NETショップから始めたばかりで、私が働いていた他の場所とはかなり異なった動作をします。私の以前の職務とは異なり、ここで書かれたソフトウェアは複数の顧客を対象としており、すべての顧客がソフトウェアの最新リリースを同時に入手できるわけではありません。そのため、「現在の製品バージョン」はありません。顧客が更新プログラムを入手すると、最後の更新以降にソフトウェアに追加されたすべての機能も入手しますが、これはかなり前のことです。ソフトウェアは高度に設定可能であり、機能のオンとオフを切り替えることができます。いわゆる「機能切り替え」です。ここではリリースサイクルが非常に厳しく、実際にはスケジュールどおりではありません。機能が完了すると、ソフトウェアが関連する顧客に展開されます。 チームは昨年だけVisual Source SafeからTeam Foundation Serverに移行しました。問題は、VSSのようにTFSを使用し続け、単一のコードブランチでチェックアウトロックを強制することです。バグ修正がフィールドに公開されるたびに(単一の顧客であっても)、TFSにあるものをすべてビルドし、バグが修正されたことをテストして顧客に展開します!(私自身は製薬および医療機器のソフトウェアのバックグラウンドから来ており、これは信じられないほどです!)。その結果、テストが行​​われなくても、半分焼き付けられた開発コードが本番環境に入ります。バグは常にリリースビルドに滑り込んでいますが、多くの場合、ビルドを取得したばかりの顧客は、バグが含まれている機能を使用しない場合、これらのバグを見ることはありません。突然、いくつかの大きなクライアントが参加し、さらに小さなクライアントが参加しました。 バグのあるコードや未完成のコードのデプロイを排除するためにソース管理オプションを検討するように頼まれましたが、チームリリースのやや非同期な性質を犠牲にしないでください。私は自分のキャリアでVSS、TFS、SVN、Bazaarを使用しましたが、TFSは私の経験のほとんどがあった場所です。 以前、私が働いていたほとんどのチームは、1か月間、開発者が直接Devで作業し、その後変更をTest then Prodにマージするか、または「ではなく」固定サイクル。Cruise ControlまたはTeam Buildのいずれかを使用して、自動ビルドが使用されました。私の以前の仕事では、BazaarはSVNの上に座って使用されていました。開発者は独自の小さな機能ブランチで作業し、変更をSVN(TeamCityに関連付けられていました)にプッシュしました。これは、変更を簡単に分離し、他の人のブランチと共有するのが簡単だったという点で便利でした。 これらのモデルの両方には、コードがプッシュされる中央のdevおよびprod(および場合によってはテスト)ブランチがありました(そしてラベルはリリースが行われたprodのビルドをマークするために使用されました...そしてこれらはバグ修正のためにブランチにされました)リリースし、devにマージします)。これはここでの作業方法にはあまり適していませんが、さまざまな機能がいつリリースされるかは決まっておらず、完了するとプッシュされます。 この要件により、「継続的インテグレーション」アプローチが崩れます。継続的インテグレーションで新しい機能を使用するには、dev-test-prodを介してプッシュする必要があり、devで未完成の作業をキャプチャします。 これを克服するには、dev-test-prodブランチを持たない機能の多い分岐モデルを使用する必要があります。むしろ、開発作業が完了するとロック、テスト、修正、ロックされる一連の機能ブランチとしてソースが存在する必要があります、テストしてからリリースしました。他の機能ブランチは、必要な場合や必要な場合に他のブランチから変更を取得できるため、最終的にすべての変更が他のすべてのユーザーに吸収されます。これは、前回の仕事で経験した純粋なバザールモデルに非常に当てはまります。 これは柔軟に聞こえますが、開発用トランクやprodブランチがどこにもないのは奇妙に思えます。災害を統合... これについての人々の考えは何ですか? 2番目の最後の質問:分散ソース管理の正確な定義について多少混乱しています:一部の人々は、TFSやSVNのような中央リポジトリがないことを示唆しているようです。 TFSには完全に機能するオフラインモードがあります)、他の人は、機能分岐と親子関係のないブランチ間のマージの容易さについてだと言います(TFSにはベースレスマージもあります!)おそらくこれは2番目の質問です!

4
リリースビルドとナイトリービルド
典型的な解決策は、ビルドサーバーで実行されているCI(継続的インテグレーション)ビルドを使用することです。これは、ソースコードの分析、ビルドの実行(デバッグ)、テストの実行、テストカバレッジの測定などを行います。 現在、通常知られている別のビルドタイプは「ナイトリービルド」です。コードドキュメントの作成、セットアップパッケージの作成、テスト環境への展開、テスト環境に対する自動(スモークまたは受け入れ)テストの実行などの遅い処理を行います。 さて、質問: リリースビルドとして3つ目の別個の「リリースビルド」を使用する方が良いですか? または、リリースモードで「Nightly build」を行い、リリースとして使用しますか? 会社で何を使用していますか? (リリースビルドでは、潜在的な製品バージョンのソース管理に何らかのタグを追加する必要もあります。)

3
ビルド自動化対デプロイ自動化対継続的統合
もっと効率的になりたいし、opsツールを効率的に使いたい。 これを念頭に置いて、私は継続的インテグレーションについてもっと学びたかったのですが、それに関して多くの異なることがあるようです。 私は実際に私の仕事(IntelliJ、WebStorm ...)でJetbrainsスーツを使っているので、それらを使い続けたいと思っていました。 私の問題は、以下の違いがわからないことです。 ビルディングオートメーション(TeamCityはこの種のソフトウェアです):リモートVCSリポジトリを使用してアプリケーションをビルドできることは知っていますが、それは素晴らしいことですが、その主な目的は何ですか?これを行う際にどのような情報が重要ですか?実際、ソフトウェアがローカルでビルドされているかどうか、チームメートも既に知っています。それでは、自動化を展開せずにそれを使用する目的は何ですか? 自動化の展開(TeamCityは簡単に実行できないようです) 継続的インテグレーション(上記の2つの組み合わせのようです) 継続的デリバリ(これは正確に何ですか?なぜ継続的インテグレーションと異なるのですか?) これをもう少し理解してもらえますか?

2
GitLabの同じサーバー上のCIランナーですか?
会社でGitLabサーバーを設定していますが、今はGitLab CIを追加しています。 このタスクを開始する前に、GitLabとGitLab CIで使用される同じサーバー上でランナーを実行する際に不利な点があるかどうかを理解したいと思います。 セキュリティ上の懸念があることを読みましたが、内部でのみ使用しているため、これが問題になるとは思いません。 何か不足していますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.