タグ付けされた質問 「builds」

エンドユーザーが本番環境で深刻なバグを見つけた場合、そのバグをカバーするために失敗した単体テストを追加し、バグが修正されるまで意図的にビルドを壊すことは理にかなっています。これに対する私の論理的根拠は、ビルドがずっと失敗していたはずだったが、自動化されたテストカバレッジが不十分だったためではなかったということです。 私の同僚の何人かは、失敗した単体テストはチェックインすべきではないという意見に異議を唱えています。通常のTDDプラクティスの観点からはこの観点に同意しますが、生産バグは異なる方法で処理する必要があると思います。既知の欠陥で成功するビルド？ 他の誰かがこのシナリオを処理するための実証済みの戦略を持っていますか？意図的にビルドを壊すことは他のチームメンバーを混乱させる可能性があることを理解していますが、それはブランチの使用方法に完全に依存します。

410 unit-testing  tdd  builds 

私のプロジェクトで最初にコミットした結果、ナイトリービルドが壊れてしまい、リリースが近づいているので人々は私を取り囲んでいます。私は誠実に聞こえると同時に、これが私の最初のコミットであり、これがこれ以上繰り返されないことをほのめかす謝罪メールを送信したいと思います。 英語が母国語ではないので、正しい単語を見つけるのに苦労しています。誰か助けてくれますか？

181 continuous-integration  builds  release 

私の組織はSVNからGitへの移行を検討しています。移動に対する1つの議論は次のとおりです。 バージョン管理はどのように行いますか？ NetBeansプラットフォームに基づいたSDKディストリビューションがあります。SVNリビジョンは単純な番号であるため、それらを使用してプラグインとSDKビルドのバージョン番号を拡張できます。Gitに移行するとき、これをどのように処理しますか？ 可能な解決策： Hudsonのビルド番号を使用する（問題：Hudsonを確認して、実際のGitバージョンと関連付ける必要があります） 夜間および安定のためにバージョンを手動でアップグレードする（問題：学習曲線、ヒューマンエラー） 他の誰かが同様の問題に遭遇してそれを解決した場合、私たちはどのように聞いてみたいです。

131 version-control  git  svn  builds  versioning 

私のプログラミングのキャリアのほとんどで、実行可能なプログラムを作成するために使用しているIDEで「ビルド/コンパイル/実行」コマンドを使用しました。これは1つのボタンで、非常に簡単です。ただし、さまざまな言語やフレームワークについて詳しく知ると、プロジェクトを実行するための「ビルドスクリプト」（ANT、Maven、Gradleなど）の話がどんどん増えています。これらの私の理解は、それらが設定の詳細を指定するコンパイラ/リンカー/魔法のプログラムメーカーへの指示であるということです-細目。 学校に戻ってメイクファイルを書いたことを覚えていますが、そのとき特別な利点はありませんでした（便利な「ビルド」ボタンのあるIDEが存在しないUnixターミナルで書くときにのみ使用しました）。それ以外にも、ビルドスクリプトがプログラムを作成するだけでなく、ホストマシンに関係なくユニットテストを実行し、リソースを保護する方法を説明する他の質問があります。 ビルドスクリプトは開発者として理解することが重要であるという感覚を揺るがすことはできませんが、意味のある説明が欲しいです。なぜビルドスクリプトを使用/作成する必要があるのですか？ Build ScriptとBuild Serverの責任は、より広い範囲での役割について説明しています。IDEの「ビルド/実行」コマンドまたは同様の単​​純なメソッドに対して、ビルドスクリプトが提供する特定の利点を探しています。

97 development-process  builds 

パッケージ管理システムが存在するプログラミング言語がいくつかあります。 TeXのCTAN PerlのCPAN Python用のPip＆Eggs Maven for Java ハスケルのカバル Rubyの宝石 NodeJSのnpm フロントエンドJavascriptおよびCSSのバウアー C＃のnuget PHPの作曲家 そのようなシステムには他の言語がありますか？CとC ++はどうですか？（それが主な質問です！）なぜそのようなシステムがないのですか？yum、apt-getまたはその他の一般的なパッケージ管理システム用のパッケージの作成は改善されていませんか？

78 c++  c  builds  packages 

前回のビルドサイクルが不十分な展開につながる多くの状況のた​​め、私はオフィスでキャンペーンを行い、専用のビルドマシンを使用して将来のすべての展開を実行し、上司はこの提案を受け入れました。 ただし、オフィスで実際のマシンを使用する代わりに、1台のマシンを他の複数のグループと共有する必要があります。また、必要な情報をすべて入力してオフィスを出て階段を降りる手間がかかります。単純なビルドを実行するためだけに別のオフィスに移動することは、なぜ私が最初にこれを提案したのか疑問に思います。 別個のビルドマシンを使用するというアイデアは、元々、自分のローカルで記述されたコードを他の複数の開発者のコ​​ードから分離し、マシン上にあったハイジャックされたファイルを展開から分離することでした。また、ClearCaseファイル管理システムに対する懸念の高まりを解決することも目的でした。これは、「依存関係がある」別のアクティビティも含めない限り、特定のビルドアクティビティの展開を拒否することがよくあります。 実際にこのプロセスを進めているので、ビルドマシンを使用する目的全体を誤解していないかどうか、そしてこのマシンをテスト、ステージング、および実稼働環境へのコード展開にのみ使用しているため、私たちの個人的な開発者テストの展開ではなく、それが何らかの目的に役立つかどうかはわかりません。 それでは、ビルドマシンを使用する実際の理由は何ですか？また、正しく使用することに近づいていますか？

75 deployment  builds 

ビルド番号について考えると、新しいナイトリービルドが作成されるたびに、新しいビルド番号が生成され、そのビルドに割り当てられます。したがって、7.0バージョンのアプリケーションでは、ナイトリービルドは7.0.1、7.0.2などになります。そうですか？それでは、ビルド番号の後のREVISIONの使用は何ですか？または、毎晩のビルド後に改訂部分が増分されますか？私はここで少し混乱しています...私たちは、各ナイトリービルドを参照してくださいBUILD？ 形式はここに記載されています：AssemblyVersion-MSDN

55 builds  versioning 

提案されたビルドシステム（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ビルド番号の使用はセマンティックバージョニングの「乱用」であると述べました。 私の質問は次のとおりです。これは正しいですか？もしそうでなければ、なぜですか？

35 continuous-integration  versioning  builds  continuous-delivery  semantic-versioning 

ですから、メイクファイルを直接作成することや、2015年にそれを行うのは馬鹿げたことです。CMakeなどのツールを知っており、実際にCMakeを頻繁に使用しています。大切なのは、CMakeはMakefileを作成して、自分でそれを行うという退屈な作業をなくすことです。もちろん、それは他の多くの素晴らしい機能を追加します...しかし、最終的にはまだMakefileです。 だから私の質問は、Makeユーティリティ全体を指すmakeに関する「時代遅れの」話ですか、それとも自分のMakefileを手動で書くというアイデアですか？私はC / C ++開発にIDEをまったく使用しません（ちょうどemacs）ので、常にMakefileを作成しました。 Makeが古いと見なされる場合、C / C ++開発者は小さな個人プロジェクトを構築するために何を使用すべきですか？

31 c++  c  builds  make  cmake 

私は同じソースコードを共有し、継続的に統合されている中規模のチームで働いていますが、私たち全員が同じブランチで作業しなければならないため、ビルドはほとんど常に壊れています。 また、壊れたビルドを軽減するために最近導入されたルールもあります。これは、ビルド中は誰もチェックインできないことを示しています。 そうは言っても、1日の間に誰もがチェックインできる10〜15分のウィンドウを持っています。 チームが成長するにつれて、チェックインの機会の窓はさらに小さくなります。そのため、開発者は変更をローカルに蓄積する必要があり、その結果、変更セットが大きくなり、変更が何も破壊しないことを保証するのがさらに難しくなります。悪循環を見ることができます。 このような環境で私が効果的に仕事を続けられるようにするために何をお勧めできますか。また、私はマネージャーではなく開発者であり、プロセスや他の人の行動をあまり変更できないことに注意してください。

25 version-control  teamwork  continuous-integration  builds  branching 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 Javaが汎用言語であり、プログラムの構築がJava言語を使用して記述できるものである場合、なぜこれがビルドファイルを記述する最良の方法ではないのか、代わりにAnt、Maven、Gradleなどのツールを使用しますか？それはもっと簡単なことではなく、また別のプログラミング言語を学ぶ必要性を排除しませんか？（ところで-この質問は、C＃などの他の言語にも適用できます）

24 java  c#  builds  build-system 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 私の長年のJavaプログラミング、最近ではScalaで、Ant、Maven、Gradle、またはJava用のビルドツールを使用したことがありません。私が働いていたすべての場所に、そのすべてを処理するビルドマネージャーがいました-開発と単体テストのためにIDEでローカルにコンパイルし、ソースコードをチェックインし、必要なことをしたビルドマネージャーに通知しました共有環境用に全員のファイルをコンパイルします。 契約の合間に、私は自分で資金を提供するプロジェクトに取り組んでおり、実際にお金を稼ぐのに十分なレベルに達しつつあります。私も潜在的な投資家を揃えており、今後数週間以内にベータ版を見せることを計画しています。 しかし、ずっとIDEのビルドボタンをクリックするだけで、Jarファイルが作成され、正常に機能します。もちろん、従来の知識では、私は自分でAnt / Maven / Gradleスクリプトを作成し、IDEの代わりにそれを使用する必要があると示唆していますが、私の状況での具体的な利点は何ですか（単独で作業）？ 私はこれらのビルドツールの使用方法について読んでいますが、IDEがワンクリックで行うこと（IDEで生成されたものプロジェクトのAnt XMLは700行を超えています）。エラーが発生しやすく、時間がかかり、私の状況では不必要に見えます。学習曲線は言うまでもありません。学習曲線は、他のすべての作業から時間を奪って、製品を人々に見せるために準備します。

22 builds  continuous-integration  maven  ant 

私のチームにおける私の役割の1つはビルドパーソンです。私は、ビルドスクリプトを維持/更新し、継続的インテグレーションサーバー上で「スムーズに」ビルドすることを確認する責任があります。私は通常、この仕事を気にしませんが、CIサーバーを常にベビーシッターしているように感じることがよくあります。 ビルドが中断した場合、作業中のストーリーを削除し、ビルドの失敗を調査する必要があるため、このジョブは時々面倒な場合があります。ビルドの失敗はチームで毎日発生します。開発者は、コミットする前にローカルでビルドしない場合があるため、CIサーバーでのテストは失敗します。この状況では、ビルドがあまりにも長く壊れないように、「悪いコミット」をした人にすぐに連絡を取りたいです。CIサーバーに、デバッグする必要のある奇妙な状態が時々（はるかに少ない頻度で）存在します。 多くの成熟したチームが継続的インテグレーションを使用していることは知っていますが、優れたプラクティスに関する資料はあまりありません。 私の問題は、継続的インテグレーションがあまり成熟していない、またはこれが単なる仕事の一部であると指摘していますか？ 従うべきいくつかの良い習慣は何ですか？成熟した継続的インテグレーションの特徴は何ですか？ 更新 いくつかのコメントに答える代わりに、代わりに更新を行います。アプリをビルドするときにビルドサーバーが実行することを正確に実行する単一のシンプルなコマンドがあります。コンパイル、すべてのユニット/統合、およびいくつかのクイックUIベースのテストを実行します。 みんなの答えを読んで、2つの大きな問題があるかもしれないと感じています。 ビルドが失敗したときにCIサーバーが十分に不平を言っていない。 開発者は、コミットが正常に実行されることを確認する責任を全員に負わないと感じています。 私のチームで物事を難しくしているのは、大規模なチーム（10人以上の開発者）がいて、仕事をしていないときでも、数人のオフショアチームメンバーがコミットしていることです。チームが大規模であり、頻繁な小さなコミットが好ましいことを確立したため、1日で実際に多くのアクティビティを行うことがあります。

22 builds  continuous-integration 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 そこにはかなりの数の異なる継続的インテグレーション（CI）フレームワークがあり、どれが最も人気があるのだろうかと思っています。勤務している企業でどのフレームワークを使用しましたか？ あるCIフレームワークが他のCIフレームワークよりも人気がある理由はありますか？おそらく、それが提供する機能、それに統合されるもの、またはその単なるマーケティングによるものでしょうか？ rubyやpythonよりも、Javaと.netの世界では継続的インテグレーションがより多く使用されているようです。どうしてこれなの？

21 java  c#  development-process  builds 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 ジョエルテストの基準の1つは、毎日のビルドです。アイデアは、ビルドが壊れた場合、それを壊した人がそれを修正するために周りにいるということです。ビルドを修正できない場合は、全員が古いバージョンをチェックアウトして作業する必要があります。一元化されたバージョン管理では、マージと分岐を可能な限り避けることが重要であるため、これがいかに悪いかを理解できますが、これは分散バージョン管理にとってささいな迷惑のように聞こえます。これに同意しますか？毎日のビルドが重要な理由は他にもありますか？

20 joel-test  version-control  builds