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

継続的インテグレーション(CI)は、フルソフトウェア製品を頻繁にスケジュールで構築および自動化したテストです。少なくとも1日に1回、多くの場合1日に数回、時にはバージョン管理システムにチェックインするたびに頻繁に行います。

6
竹対 Hudson(別名Jenkins)とその他のCIシステム[終了]
現在のところ、この質問はQ&A形式には適していません。事実、参考文献、専門知識によって回答が裏付けられることを期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問が改善され、場合によっては再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 HudsonとBambooの両方の経験がある人はいますか?これらの製品の相対的な長所と短所について何か考えはありますか? さて、皆さんは他のCI製品について言及し続けるので、これをさらに公開します。これが私の一般的な問題です。新しいプロジェクトのCIシステムをセットアップしたい。このプロジェクトには、Javaコンポーネント(WARおよびJAR)、いくつかのpythonモジュール、さらには.NETコンポーネントが含まれる可能性があります。だから私はできるCIサーバーが欲しい: 複数の言語を処理し、 アーティファクトをサーバーにデプロイします(つまり、すべてのユニットテストに合格した場合はwarをデプロイします)。 まともなコードカバレッジツールと統合されたものも欲しいです。 見栄えの良いレポートは適切ですが、必須ではありません。 問題が発生した場合の複数の通知メカニズム。 私はホスティングについて心配していません。ローカルサーバーまたはAmazonインスタンスで実行します。 また、これは空のパイかもしれませんが、iPhoneアプリを構築できるものはありますか?

5
GitHubリポジトリにTravisビルドステータスを表示する
私は最近、GitHubでprまたはcommitのTravisビルドステータスを参照してリポジトリを参照していることを覚えています(ただし、場所を見つけることができません)。私はTravisビルドステータスイメージについてではREADME.mdなく、実際のGitHub機能(フレンドリーなチェックマークが付いた緑色のボックス)について話しています。 私のコミットはTravisでうまく構築されていますが、GitHubに結果を表示したいのですが(現在はそうではありません)。これを有効にする方法を教えてください。 更新 ここに例が見つかりました-「Travis-CIビルドに合格しました」と書かれた小さな緑色のチェックマークを参照してください。


11
継続的な統合のためのCruiseControl [.Net]とTeamCityの比較
実務経験に基づいて、どの自動化ビルド環境を検討するかをお伺いします。いくつかの.NetといくつかのJava開発を計画しているので、これらの両方のプラットフォームをサポートするツールが欲しいです。 私は周りを読んでいて、stackoverflow開発で使用されるCruiseControl.NETと、さまざまなOSプラットフォーム上でさまざまなプログラミング言語に基づくビルドエージェントをサポートするTeamCityについて知りました。それで、あなたがそれらの両方でいくつかの実際的な経験を持っているなら、あなたはどちらを好みますか、そしてなぜですか? 現在、私はツールの使いやすさと管理に主に関心がありますが、CCはオープンソースであり、TCは、実行するプロジェクトが多い場合のある時点でライセンスの対象となります(なぜなら、私は少量のプロジェクトで必要です)。 また、上記のツールが他にもあり、推奨する価値があると思われる場合は、お気軽にディスカッションに含めてください。

14
Pythonの「きれいな」継続的統合
これは少し無駄な質問ですが、BuildBotの出力は特に見た目が良くありません。 たとえば、と比較して phpUnderControl ジェンキンス ハドソン CruiseControl.rb ..その他、BuildBotはかなり古く見えます。 私は現在ハドソンで遊んでいますが、非常にJava中心です(このガイドを使用すると、BuildBotよりもセットアップが簡単で、より多くの情報が生成されます)。 基本的に:Pythonを対象とした継続的な統合システムはありますか? 更新:今回から、JenkinsプロジェクトがパッケージのコミュニティバージョンとしてHudsonに置き換わりました。元の作者もこのプロジェクトに移動しました。Jenkinsは、Ubuntu / Debian、RedHat / Fedora / CentOSなどの標準パッケージになりました。次の更新はまだ本質的に正しいです。Jenkinsでこれを行うための開始点は異なります。 更新:いくつかの代替案を試した後、私はハドソンに固執すると思います。整合性は素晴らしくシンプルでしたが、かなり制限されていました。Buildbotは、私が使用していたような1台のマシンですべてを実行するよりも、多数のビルドスレーブを使用する方が適していると思います。 Pythonプロジェクト用にHudsonを設定するのは非常に簡単でした。 Hudsonをhttp://hudson-ci.org/からダウンロードします。 で実行する java -jar hudson.war のデフォルトアドレスでWebインターフェイスを開きます http://localhost:8080 ハドソン、プラグインの管理に移動し、「更新」などをクリックします Gitプラグインをインストールします(gitHudsonのグローバル設定でパスを設定する必要がありました)。 新しいプロジェクトを作成し、リポジトリ、SCMポーリング間隔などを入力します まだインストールされnosetestsていeasy_installない場合は、 ビルドステップで、 nosetests --with-xunit --verbose 「JUnitテスト結果レポートの公開」をチェックし、「テストレポートXML」を **/nosetests.xml それだけで十分です。メール通知を設定でき、プラグインは一見の価値があります。私が現在Pythonプロジェクトで使用しているいくつか: コード行をカウントするSLOCCountプラグイン(そしてそれをグラフ化します!)- sloccountを個別にインストールする必要があります PyLint出力を解析するための違反(警告しきい値を設定し、各ビルドでの違反の数をグラフ化できます) Coberturaは、coverage.py出力を解析できます。Nosetestは、テストの実行中にカバレッジを収集できますnosetests --with-coverage(これにより出力がに書き込まれます**/coverage.xml)。

10
複数のビルド構成に異なるapp.configを選択する方法
私が持っているDLL型プロジェクト MSTestを統合テストが含まれています。私のマシンではテストに合格し、CIサーバーでも同じようにしたいと思っています(TeamCityを使用しています)。しかし、app.configの一部の設定を微調整する必要があるため、テストは失敗します。これが、CIサーバーの設定を保持する別の2番目のapp.configファイルがあると考えていた理由です。 だから私はしたいと思います / Sln / Proj app.config(これはVSで必要とされると思います) app.Release.config(これはスタンドアロンの独立した構成ファイルです) したがって、CIのビルド構成でリリース構成を選択した場合、app.configではなくapp.Release.configファイルを使用したいと思います。 問題 これは、単純な.dllタイプのプロジェクトでは簡単ではないようです。Webプロジェクトの場合、Web構成の変換を行うことができます。DLLタイプのプロジェクトでこれらの変換を行う方法をハックで見つけましたが、私はハックの大ファンではありません。 質問 .NETプロジェクト(デバッグ、リリースなど)のビルド構成に応じてapp.configファイルを微調整する標準的なアプローチは何ですか?

12
CIプラットフォーム(Hudson)を介してC#アセンブリバージョンを自動インクリメントするにはどうすればよいですか?
私と私のグループは、アセンブリのバージョン番号をインクリメントすることに恐ろしく、1.0.0.0バージョンのアセンブリを頻繁に出荷しています。明らかに、これは多くの頭痛の種です。 CIプラットフォームを介してプラクティスを大幅に改善しているassemblyinfo.csので、ファイル内の値を自動インクリメントして、アセンブリのバージョンがそのアセンブリのコード変更で自動更新されるように設定したいと思います。 以前に(Hudsonを見つける前に)msbuildまたはコマンドライン(覚えていない)を介して値をインクリメントする方法をセットアップしましたが、Hudsonを使用すると、SVNリポジトリが更新され、別のビルドがトリガーされます。Hudsonが1時間ごとにSVNをポーリングするため、遅い無限ループが発生します。 ハドソンにバージョン番号を増加させることは悪い考えですか?それを行う別の方法は何でしょうか? 理想的には、ソリューションの私の基準は次のようなものになるでしょう: ビルドassemblyinfo.cs前にビルド番号をインクリメントします 変更されたアセンブリのビルド番号のみをインクリメントします。Hudsonはビルドを行うたびにプロジェクトフォルダーを一掃するため、これは不可能である可能性があります 変更されたassemblyinfo.csをコードリポジトリにコミットします(現在はVisualSVN) Hudsonが次に変更をスキャンするときに新しいビルドをトリガーしません 私の頭の中でこれを解決すると、バッチファイル/コマンドを介してこのほとんどの解決策を簡単に思いつくことができましたが、私のすべてのアイデアにより、次にスキャンするときにHudsonが新しいビルドをトリガーするようになります。私は私のためにすべてを行う誰かを探しているのではなく、正しい方向に私を向けるだけで、おそらくHudsonに特定のSVNコミットを無視させるテクニックなどです。 これまでに見つけたものはすべて、バージョン番号を自動的にインクリメントする方法を説明する記事にすぎません。無限ループになる可能性のあるCIプラットフォームは考慮されていません。


3
msbuildをC#6にアップグレードする方法
プロジェクトでC#6を使用したい(null伝播、その他の機能)。 私は自分のPCにVS 2015をインストールしました。それは見事に機能し、次のようなテストコードをビルドします。 var user = new SingleUserModel(); //all model fields are null var test = user.User?.Avatar?["blah"]; しかし、プロジェクトをリポジトリにプッシュし、CIがそれをビルドし始めると、サポートされていないためビルドが失敗します?。 CIサーバーにもVS2015をインストールしましたが、使用していないようです。私に何ができる? CI-CruiseControl .NETビルド C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

4
Jenkins CIパイプラインスクリプトはメソッドgroovy.lang.GroovyObjectの使用を許可されていません
JavaプロジェクトのコンパイルにJenkins 2を使用しています。pom.xmlからバージョンを読み取りたいのですが、次の例に従っていました。 https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md 例は提案します: ファイルシステムへのアクセスにセキュリティ上の問題があるようですが、ファイルシステムが何を与えているのか(またはその理由が)わかりません。 私は例とは少し違うだけです: def version() { String path = pwd(); def matcher = readFile("${path}/pom.xml") =~ '<version>(.+)</version>' return matcher ? matcher[0][1] : null } 「バージョン」メソッドを実行すると発生するエラー: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject invokeMethod java.lang.String java.lang.Object (org.codehaus.groovy.runtime.GStringImpl call org.codehaus.groovy.runtime.GStringImpl) at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:165) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:117) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:103) at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149) at …

18
「ビルドサーバー」のポイントは何ですか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 この質問を改善する 私は非常に大規模な組織で働いたことはなく、「ビルドサーバー」を持つ会社で働いたことはありません。 彼らの目的は何ですか?開発者がプロ​​ジェクトをローカルマシンでビルドしていないのはなぜですか?プロジェクトによっては、妥当な時間でそれを構築するために、より強力なマシンが必要となるほど大きいものがありますか? ビルドサーバーが有用であると私が思う唯一の場所は、ビルドサーバーと継続的に統合して、リポジトリにコミットするものを常にビルドすることです。十分な規模のプロジェクトに取り組んでいないのですか? 誰か、私を啓発してください:ビルドサーバーの目的は何ですか?

9
継続的な統合のためのHudsonまたはTeamcity?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 私たちは、使用するCIツールを探しているJavaショップです。HudsonとTeamcityはどちらも無料のようですが、Teamcityはより洗練されており、サポートが強化されています。 なぜなぜHudsonを使用するのか、また誰かが/に対して反対の意見を述べることができるのかと思っていましたか?

12
継続的インテグレーションを行う場合の最良の分岐戦略は?
継続的インテグレーションを行う場合に使用する最適な分岐戦略は何ですか? リリースブランチ:トランクで開発し、リリースごとにブランチを保持します。 機能の分岐:各機能を別々の分岐で開発し、安定した場合にのみマージします。 これらの戦略の両方を一緒に使用することは理にかなっていますか?同様に、リリースごとに分岐しますが、大規模な機能にも分岐しますか?これらの戦略の1つは、継続的インテグレーションとうまくかみ合いますか 不安定なトランクを使用している場合、継続的インテグレーションを使用しても意味がありますか?

4
CIサーバーでの.NET 4.0ビルドの問題
誰かがCIサーバーにVisual Studio 2010をインストールせずに.NET 4.0アプリケーションをCIサーバーでコンパイルできるようにしましたか? .NET 4.0用のSDKはありません。CIサーバーに.NET 4.0をインストールしました。Msbuild.exeは単純なプロジェクトで機能し、次の警告を出します。 (GetReferenceAssemblyPathsターゲット)-> C:\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets(847,9):警告MSB3644:フレームワーク ".NETFramework、Version = v4.0"の参照アセンブリ見つかりませんでした。これを解決するには、このフレームワークバージョンのSDKまたはターゲットパックをインストールするか、SDKまたはターゲットパックがインストールされているフレームワークのバージョンにアプリケーションを再ターゲットします。アセンブリはグローバルアセンブリキャッシュ(GAC)から解決され、参照アセンブリの代わりに使用されることに注意してください。したがって、アセンブリが意図したフレームワークを正しくターゲットにしていない可能性があります。

7
Jenkinsスクリプトパイプラインまたは宣言型パイプライン
古いスタイルのプロジェクトベースのワークフローを、Jenkinsに基づくパイプラインに変換しようとしています。通過する間にドキュメント私は2つの異なる名前の構文がある見つけscriptedとはdeclarative。declarative最近のJenkins Web 構文リリースなど(2016年末)。新しい構文リリースがありますが、Jenkinsはスクリプト化された構文もサポートしています。 さて、これら2つのタイプのどちらがどの状況に最適であるかはわかりません。scripted構文はまもなく廃止されますか?ではdeclarative、ジェンキンスパイプラインの将来はどうなるのでしょうか? これらの2つの構文タイプについて考えを共有できる人なら誰でも。

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