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

ソロプロジェクトを行う場合-CIツールを使用してリポジトリからビルドしますか？私はチーム環境でハドソンとクルーズコントロールを使用しました。誰かがチェックインしたらすぐにビルドすることが不可欠です。 バージョン管理の価値はまだ明らかだと思いますが、ローカルマシンでビルドしたばかりで、誰もコミットしていないように、コミットするたびにビルドする必要がありますか？

18 version-control  continuous-integration  builds  solo-development 

私はCMakeを使用してプロジェクトIDE / makefileを生成していますが、それでもコンパイル済みファイルを操作したり、コードを生成したりするためにカスタムの「スクリプト」を呼び出す必要があります。 以前のプロジェクトではPythonを使用していましたが大丈夫でしたが、現在作業中の2つの非常に大きなプロジェクトで多くの依存関係を管理するのが大変なため、どこでも依存関係を最小限に抑えたいと思います。 誰かが、そのための言語依存関係を追加する代わりに、C ++を使用してビルドスクリプトを作成するように私に提案しました。プロジェクトのテーマはすでにC ++を使用しているため、いくつかの利点があります。 プロジェクト全体をビルドするには、C ++コンパイラとCMakeのみが必要であり、他には何も必要ありません（他の依存関係はすべてCまたはC ++です）。 C ++の型安全性（最新のC ++を使用する場合）により、すべてが「正しく」なりやすくなります。 また、私がよく知っている言語でもあるため、優れたPythonコードを書くことができたとしても、安心して使用できます。 実行速度の潜在的な向上（ただし、実際に知覚できるとは思わない）; しかし、いくつかの欠点があるかもしれないと思うし、私はまだ試していないので、本当の影響がわからない： コードを書くのに時間がかかるかもしれません（私はC ++で十分に効率が良いのですぐに動作するものを書くので確信がないと言ったので、このシステムでは書くのにそれほど長くはないかもしれません） tこの場合は問題になります）; 入力として読み込むテキストファイルはすべてUTF-8であると想定する必要があります。実行時にC ++で簡単にチェックできるかどうかはわかりませんが、言語ではチェックされません。 C ++のライブラリは、スクリプト言語よりも管理が困難です。 私には経験と洞察力が欠けているので、長所と短所が足りないかもしれません。質問は次のとおりです。これにC ++を使用するのは理にかなっていますか？報告する経験はありますか、また重要な利点と欠点がありますか？

15 c++  builds  cmake  build-system 

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

15 continuous-integration  automation  builds 

開発者IDEでコンパイルされたクラスを単純化するバッチコマンドファイル（windows .bat）を、より包括的なAntビルド（つまり、CVSから取得、コンパイル、jar、アーカイブ、電子メールなど）でゆっくりと置き換えています。 Antで多くの時間を学習（および問題のデバッグ）に費やしてきたので、これらのタスクに使用するのが最も快適です。しかし、Antは、私が最初に学習を始めたときと同じように広く使用されているのか、それとも「世界は新しいものに（そしておそらくよりスマートに）変わったのか」と疑問に思います。（たとえば、Mavenビルドマテリアルが配布されるようになりましたが、これは使用したことがありません。） この質問の実際の重要な点は、新しい開発者にAntを学ぶように勧めるかどうか、またはビルドのために他の何かを学ぶべきかどうかです。 私は決してトレンドを熟知しているわけではないので、他のJava開発者から彼らが最高のビルドツールだと思うこと、そして新しい開発者が学ばなければならないと思うことを聞くのは素晴らしいことです。

14 java  training  maven  builds  ant 

ジョエルテストから： ワンステップでビルドを作成できますか？ 私にはできないと言わざるを得ない。現在、展開するために実行する必要があるアイテムのスプレッドシートリストがあるWebアプリで作業しています。だから私の質問はこれをどのように自動化できますか？組織全体である必要がありますか？ヒント/テクニック？

14 tools  builds  automation 

私は最近、自分のアプリケーションに統合したオープンソースソフトウェアパッケージで、かなり厄介な（確認済みの）バグに遭遇しました。パブリックイシュートラッカーによると、このバグはソフトウェアの最新リリースで解決されています。 特定のモジュールの高価なリファクタリングを避けるためにバグ修正が必要になる場合がありますが、技術的および/または政治的な理由により、最新リリースにアップグレードすることはできません。 行われたコードの変更を調べると、修正は非常に簡単に思えるので、実行可能なオプションは自分でコードにパッチを当て、現在承認されているバージョンのソフトウェアを再コンパイルすることだと感じますが、中傷者はこれがほとんど常に悪い考えだと主張したいそれは危険であり、面倒な複雑さをもたらします。 彼らの目には、このコードの変更は私たちが使用するためだけに行われたため、コードベースの一部である必要があります。つまり、オープンソースソフトウェアをサードパーティの依存関係として導入するのではなく、新しいプロジェクトとして導入して組み込む必要がありますビルドプロセスへの自動ビルド。 私にとっては、ソース管理リポジトリからコードをソース管理リポジトリにプルするため、これは間違っていると思います。その前に行われたコード変更の背後にある歴史を失います。また、実行する必要のあるこのような小さなコードの変更には、非常に複雑すぎるもののように思えます。 この場合、上記を行うのは悪い考えでしょうか？もしそうなら、オープンソースを変更する必要があるとき、理想的な状況は何ですか？

13 open-source  builds  software-patches 

私のコードでやりたいことの1つは、管理しやすい部分にリファクタリングすることです。しかし、ソフトウェアの構築に関しては、私が最終的に使用するビルド自動化ソフトウェア（最近はGNU MakeまたはSCons）が完全に混乱することになります。入力ファイルは、簡単なリファクタリングに逆らう長いスクリプトのように見えます。何らかの方法でそれらをリファクタリングできるようにしたいのですが、「関数」の概念は、プログラミング言語でのビルド自動化ソフトウェアとまったく同じように動作しないため、管理しやすい記述が難しいと感じていますやや複雑なプロジェクトのMakefileまたはSConscriptファイル。 ビルド自動化ソフトウェアの管理可能な入力ファイルを作成することについて、何かアドバイスはありますか？ソフトウェアに依存しないアドバイスが最適ですが、特定のビルド自動化ツール、特にMakeやSConsについてのアドバイスも役立ちます。これは私がプロジェクトで使用しているものだからです。 編集： Thorbjørnが指摘したように、コンテキストと使用例をいくつか追加する必要があります。私は化学工学の博士号を取得しており、計算科学の研究を行っています。（私はSciComp.SEのpro modです。訪問する人のためです。）私のプロジェクトは通常、いくつかの重いスクリプト言語（Python、Python、C ++、Fortran） 、Perl）を使用してプロトタイプを作成し、場合によっては、プロトタイプ作成または技術的な目的でドメイン固有の言語を使用します。 およそ250行の範囲で、以下に2つの例を追加しました。私にとっての問題は、一般的にモジュール性の欠如です。これらのプロジェクトの一部はモジュラーユニットに編成できます。これらのラインに沿ってビルドの一部を抽象化し、私と将来のメンテナーが追跡しやすくするのは良いことです。各スクリプトを複数のファイルに分割することは、頭の中でいじくり回してきた1つのソリューションです。 2番目の例は特に重要です。なぜなら、すぐに多数のファイルが必要になるからです。 以下は、265行Makefileが実際のプロジェクトから取得し、できる限り整理したものです。 #!/usr/bin/make #Directory containing DAEPACK library folder daepack_root = . library = $(daepack_root)/lib wrappers = $(daepack_root)/Wrappers/DSL48S c_headers = parser.h problemSizes.h f77_headers=problemSizes.f commonParam.f f90_headers=problemSizes.f commonParam.f90 includes = -I. -Iinclude -I/usr/include/glib-2.0 \ -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 \ -I/usr/include/libgdome -I/usr/include/gtest/ #Fortran 77 environment variables f77=gfortran …

13 refactoring  builds 

これはJavaで書かれたWebプロジェクトです。 それで、ビルドとデプロイのスクリプトを書いています。ビルドを作成するために、antを使用しました。継続的なビルドはJenkinsで行われます。 ビルドは3つの異なる成果物を生成します。 戦争ファイル レイアウト付きのzip 画像を含むzip これまでのところ、これでいいのですが、今度はdeployスクリプトを記述する必要があります。 サーバー1で実行されているTomcatに戦争（アーティファクト1）をデプロイします サーバー1のアーティファクト2を特定のディレクトリに配置します サーバー2のアーティファクト3を特定のディレクトリに配置します そこで同僚と話していて、正しいサーバーに配置したときにこれらのアーティファクトをデプロイするアーティファクト（多分deploy.xml）も生成する必要があると彼は言いました。 したがって、別のスクリプトがあります。 ジェンキンスのアーティファクトをダウンロードする 各サーバーにscpし、そこにdeploy.xmlを配置します deploy.xmlをリモートで呼び出す 私を少し不快にしているのは、build.xmlをビルドアーティファクトとして持つ行為です。この背後にある動機は、VCSリポジトリにアクセスする必要なしにデプロイできるため、ビルドは自己完結型になります。つまり、すべてのビルドはJenkinsによって生成されたものでのみ本番稼働できます。 配置スクリプトはどこに配置する必要がありますか？それらはVCSにのみあるべきですか、それともビルドアーティファクトであるべきですか？

13 deployment  jenkins  builds 

詳しく説明すると、1人のプロジェクト（チームのソース管理、ドキュメント、ビルドなど）を実行している間に配置する必要があると考える人々と、2人目が来るまで何をする必要がないかを知ることに興味があります。プロジェクトに。 このシナリオを経験したことがある人なら誰でも、彼らの洞察に感謝します。

13 project-management  version-control  development-process  documentation  builds 

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

13 builds  release  continuous-integration 

マイクロフロントエンドの私の理解は、彼らが解決する重要な問題は、企業が複数の可能な異なるチームを持ち、大規模なWebアプリケーションを構成するために使用される個々のコンポーネント/スモールアプリで作業するのを支援することです。 ここで解決されている重要な問題は、複数のチームが独立して作業し、大規模なコンポジットを構築できる能力です。問題は、エンドユーザー向けに無駄のないリリースバンドルを用意することではありません。その理解は正しいですか？ 大きなWebアプリケーションを作成するために複数のスモールアプリを使用している場合、同じJavascriptライブラリ（Lodashなど）をエンドユーザーのブラウザーに配送する複数のスモールアプリを潜在的に含めることができるというのは本当ですか？個々のベンダーバンドルは、ある程度の重複/冗長コードがユーザーに送信される原因になりますか？ これは、フロントエンドアプリケーションの設計中に心配する必要がある問題ではありませんか？

12 optimization  builds  front-end  angular2 

ビルドスクリプトとビルドサーバーの責任について明確にする必要があります。 継続的な統合とビルドに関するいくつかのネット上の記事を読みました。含む F5キーはビルドプロセスではありません ビルドサーバー：プロジェクトのハートモニター 毎日のビルドはあなたの友達 そして、私たちのソフトウェアのビルドプロセスについてアドバイザーと会話しました。彼は非常に経験豊富であるため、私は彼の発言を信頼しますが、混乱が残りました。 私が理解しているように、私の研究から（そして私が尋ねているのでここで私を修正してください）理想は次のようになるはずです： すべてのプロジェクトにはビルドスクリプトがあります このスクリプトはプロジェクトをビルドします このスクリプトは、依存関係が以前に構築されていることを確認します 依存関係は他のプロジェクトになる可能性があるため、独自のビルドスクリプトを使用すると、ツリーのような階層が生じます。すべてのプロジェクトとアプリケーションをビルドするトップビルドスクリプトがある場合があります。 ただし、ビルドサーバーの責任は次のとおりです。 リポジトリをチェックアウトする ビルドをトリガーする トリガーテストおよびその他のQAツール アーティファクトを利用可能にする これは、手動で、夜間に、またはリポジトリが変更されるたびにトリガーされます。 私のアドバイザーの目的は、私が理解しているように、1つのビルドスクリプトは柔軟性がなく、維持できない方法であるということです（レガシーコードベース用に作成するのに非常に時間がかかるという事実は別として）。また、ビルドサーバーは依存関係を維持する必要があります。たとえば、新しい依存関係を作成するときに古い依存関係を使用すると失敗します。特にAnt、具体的な主題であったため、コードベースで使用されるあらゆる種類の異なるテクノロジーを構築することはできず、依存関係を維持することもできません。 目的を詳しく説明して、責任を明確にしてください。

12 version-control  continuous-integration  builds 

同僚と私は、現在のgitリポジトリから派生したバージョンをビルドするたびにコードに統合することの問題/メリットを交互に議論/議論しています。 メリットは次のとおりです。 バージョン番号を更新する際に人的エラーを心配する必要はありません デバイスで見つかったものと、そのソースコードのソースコードとの間のトレーサビリティ （私たちにとって）発生した問題は次のとおりです。 IDE派生ビルドシステム（MPLABXなど）は、これらの種類のフックをどこに配置するのかを把握するのを難しくする可能性があります（最終的にはかなり安っぽくなります） これをビルドスクリプト/メイクファイルに実際に統合するためのさらなる作業 特定のビルドアプローチ（たとえば、1人がXCodeと他のMPLABXを使用してビルドした場合）へのカップリングは、ダウンストリームのサプライズを作成する可能性があります だから私たちは他の人がこの議論に上陸した場所に興味があります。議論が逸話になるのは本当に簡単です。エンドツーエンドの自動化に固執し、先行作業とそれが生み出すカップリングの量を掛ける人が大勢います。そして、議論の反対側には多くの人がいます。彼らは、最も簡単なことをして、リスクを抱えて生きています。 どの側に着陸するのが最適であるかについて、合理的な答えはありますか？

12 c  git  builds  build-system 

私は今、複数ファイルのプログラムを書いていますが、何らかの理由で「make」だけを実行しているようです（ほとんどの状況で直感的に実行する必要があると思うように）。問題の詳細を提供できると思いますが、重要なことは、「make clean」を使用したときに実行されることです。だから、誰かが「メイク」ではなく「メイククリーン」を実行するための一般的な経験則を知っているのだろうかと思っていました

11 c++  builds  make 

3〜4種類のオープンソースC / C ++ライブラリを使用するプロジェクトがあります。 これらのライブラリをいくつかのプラットフォーム用にビルドし、プロジェクトのさまざまなプラットフォーム用のインクルードファイルとスタティックライブラリをチェックインしました。 しかし、私はいくつかの問題に苦労しています。これらのプロジェクトはすべて、依存関係管理に関するものです。そして、私はベストプラクティスのアドバイスを探しています。 1）何を使用しているのか正確に知るにはどうすればよいですか？ 静的libのバージョンを取得する方法がありません。結果として、使用している静的libのバージョンを何らかの方法で追跡する必要があります（ビルド元のコミットのSHAである可能性があります）？ これらのライブラリをいつアップグレードするかを理解する必要がある場合、これは特に重要です。 2）ビルドを再現するにはどうすればよいですか？ 特定のプラットフォーム用の特定のライブラリーを構築するのに苦労したかもしれません。それを理解するのにしばらく時間がかかりました。 次回同じライブラリを作成する必要があるのは、半年後（なんらかの理由でアップグレードが必要になるとき）になる可能性があります。しかし、そのときまでに、何がどのライブラリで構築されたのかはっきり覚えていません長い間なくなります。 3）これらのライブラリをフォークしてソースコードのコピーを作成する必要がありますか？ これはそれほど問題ではありません。しかし、それはまだ問題です。ビルドが再現可能であることを確認するのは良いことです（そのようなソースコードが必要です）。

11 c++  c  builds  dependency-management