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

継続的インテグレーション（CI）は、開発者の作業コードコピーを共有コードベースに頻繁にマージして、統合の問題を防止または最小化するプロセスです。[Jenkins]や[Travis-CI]などの特定のCIシステムに関する質問については、代わりにこれらのタグを使用してください。

4
Jenkinsを適切にスケーリングする方法は？
私のプロジェクトでは、Jenkins Master + 1 Jenkins slave（2エグゼキューター）を実行するAWSサーバーが1つあり 、ビルドパワーを増強するために3つのオプションがあります： スケールアップ：AWSインスタンスを大きくし、エグゼキューターを追加します。 スケールアップ：AWSインスタンスを大きくし、別のjenkinsスレーブプロセスを追加します。 スケールアウト：jenkinsスレーブを使用して別のAWSインスタンスを作成し、マスターに接続します 私たちは大規模な組織であり、現在のジェンキンスマスターは必要なすべての場所にすでにアクセスしているため、2。を実行したいと考えています。オプション3。「新しいサーバー」は、数週間かかる官僚的な承認をさらに必要とするため、複雑です。 だから私の質問は： オプション2に技術的な問題はありますか？。各ジェンキンススレーブのエグゼキューターは、他のスレーブエグゼキューターを知らないのでしょうか？ 一般的に、ジェンキンスをスケーリングするための最良のアプローチは何ですか？スケールアップまたはスケールアウト？
4
継続的インテグレーションは、継続的な配信/展開とどのように関係していますか？
これは、continuous-integrationの現在の内容からの引用です： ...統合の問題を防止または最小化するために、開発者の作業コードのコピーを共有コードベースに頻繁にマージするプロセス。 わかった。しかし、その後、継続的な配信と 継続的な展開もあり、それは私が継続的に少し迷子になるところです： どのように継続的な統合はに関連し、連続配信および/または連続展開を経由して行（複数可）に沿ってどこかにいることを想定して、integrationあなたは結局deliveringすべてが可能になるターゲット環境でdeployed。 継続的デリバリーと継続的デプロイメントの違いは何ですか？ 昔、DevOpsがDevOpsと呼ばれる前に、次のような新しいDevOps用語を理解するのに役立つ用語を使用していました。 pre-prodターゲットに昇格（または降格）し、必要に応じて何らかのタイプの再生成プロセス（コンパイル、バインドなど）と組み合わせて、関連するすべてのコンポーネントを実行可能ファイルにまとめます。それは、継続的インテグレーションに似ている/近いはずなのか、そうでないのか？ FTPのようなものを使用してターゲット環境に配布します（標準のコピーがギャップを埋めることができない場合）が、ターゲットでまだアクティブにしないでください。それが連続配信に似ている/近いはずなのか、そうでないのか？ インストール（またはアクティベートそれは近い/類似していなければならないものだなど、）一部のターゲット環境では、バインド、停止/起動操作のようなものと組み合わせて連続展開、かどうか？
5
テスト環境で継続的な統合に起因する不安定性を回避する方法は？
ターゲット環境を頻繁に更新する継続的統合プロセスを使用しているため、「変更」があるたびに「すぐに」変更をテストできます。それはCIの目標の一部ですよね？ ただし、管理者や顧客など、テストサイクルに関係する他の人もいると仮定します。他の人にあなたの今後の変更をレビュー（破壊？）させようとするのは理にかなっていますよね？ しかし、他の人々が真剣にテストしようとしている環境で継続的に変更を提供し続けると、次のような複数の問題が発生する可能性があります。 they 問題を報告するのに時間を浪費する可能性があり、（詳細な）レポートを保存するまでに、問題を自分で再現することさえできなくなります（たとえば、誤って同じ問題に遭遇し、環境で既に修正しているため）。 you 何らかの問題に遭遇した環境はもはや同一ではないため、彼らが報告した問題を再現できない可能性があります（あなた（!!!）が環境をオーバーレイした可能性があります）。 それで、あなたはそのような（イライラする）状況を避けるために何をすることができますか（物事を構成する方法？）
4
複雑な分岐現実から単一分岐モデルに移行する方法は？
大規模な組織では、ウォーターフォール手法を使用すると、通常、非常に複雑な分岐構造（ブランチスパゲッティ）が発生します。 複雑な分岐現実からトランクベースの開発のような単一分岐モデルへの移行に使用できる分岐戦略は何ですか？ 更新： 明確にするために、質問は移行/移行自体に関するものであり、前後の方法論に関するものではなく、かなり明確です。 「今日のEOBでは、まだ数十億のブランチがある滝ですが、明日はトランクベースの単一ブランチCIに切り替えます」とは言えません。
3
AWSのシンプルなCI / CDコンテナー
AWS Code Pipeline、Code Buildを使用して新しいDockerコンテナーを作成し、ECRにプッシュしています。 私のアプリケーションは、シンプルで単純な単一コンテナーベースです。現在実行中のコンテナをプルダウンし、ECSレジストリから新しいコンテナを再起動するための摩擦の少ないアプローチ（コードパイプラインを介したコードビルドの出力）。 EC2ユーザーデータを使用してCloudFormationを試し、一方にカスタムスクリプトを、もう一方にECSを使用してCloudFormationを試しました（まだ成功していません）。もっと明確でシンプルなアプローチが必要だと強く感じています。
2
クラウドリソースの使用状況を追跡するにはどうすればよいですか？
JenkinsでAWSアプリケーションのデプロイを自動化しようとしています。 現在、UATなどのいずれかの環境でアプリケーションを更新する場合は、Dockerイメージをビルドし、現在のECSタスクを見つけて新しいイメージで更新し、実行中のECSクラスターを見つけて、タスクを更新します。 概して、継続的インテグレーション環境でクラウドリソースID（ECSクラスターID、ECSタスクID、EC2 IDなど）を追跡するためのベストプラクティスは何ですか？
2
複数のiOSプロジェクトの継続的統合インフラストラクチャ
iOS開発者として、私はこれまでに開発中のiOSプロジェクト用にCIおよびCCQ（= Continuous Code Quality）インフラストラクチャを作成しようとしていました。ほぼすべてのWebおよびAndroidプロジェクトにJenkinsとSonarQubeを使用しています（VM foreachプロジェクトを使用し、CIとCCQのインストールと構成は自動化されています）。しかし、iOSプロジェクトの場合、JenkinsはmacOSを実行しているコンピューターでビルドを行う必要があるため、そのための完璧なソリューションがあるかどうかはわかりません。 macOSを仮想化するソリューションを探していました。各プロジェクトで、仮想macOSを作成し、ビルドを処理するためにそこにJenkinsをスレーブとしてインストールします。ソリューションは完璧に見えましたが、macOSで2つ以上のVMを実行することは違法であるようです（もちろん、Macコンピューターでのみ） http://images.apple.com/legal/sla/docs/macOS1012.pdf ->ポイント2.B。したがって、これは私の場合の解決策ではありません。 私が読んだ別の一般的な解決策は、すべてのプロジェクトのすべてのビルドを処理するMacコンピューター（MacMiniかもしれません）を持つことです。この実装についてどう思いますか？いくつのプロジェクトを処理できますか？開発者は自分のプロジェクト（特にSonarQube）でいくつかの設定を行う必要があるかもしれませんが、安全ですか？ 異なるポートを使用して、同じマシン上で複数のJenkinsおよびSonarQubeインスタンスを使用できますか？これは考慮すべき解決策でさえありますか？ 上記のソリューションよりも優れている可能性のある他の実行可能なソリューションはありますか？ 注：Jenkins + SonarQubeのデュオにはこだわりません。iOS開発に適した他のツールがある場合は、それらを共有してください。
3
gitlabCIを使用してソースコードにタグを付ける方法
gitlabを環境に新しく導入し、gitlab CIを使用してCI CDパイプラインを作成しようとしました。以下のように、.gitlab-ci.ymlを使用してパイプラインを作成し、アーティファクトをアーカイブすることで、いくつかのMavenゴールを実行することで、より良い進歩を得ました。機能しないスクリプトの後にタグを付けようとしました。今、私はどのようにgitタグを私のソースコードに自動化できるかを理解しようとしています。masterブランチが正常にビルドされた後、ソースコードのタグを作成したいと思います。セマンティックバージョンを使用して、ソースコードにタグを付けています。最後に、マスターがビルドに成功したときはいつでも、マスターブランチにタグを作成したいと思います。 image: maven:3.5-jdk-8-alpine stages: - build - deploy - tag maven_build: stage: build script: - mvn clean package artifacts: paths: - target/*.jar after_script: - ls -a - cd target && ls -a - git --version - git tag -a 1.0.15 -m "Version created by gitlab-ci Build" - git …
1
「Push on Green」とは何ですか？
Googleや他のDevOps組織内で、彼らは「Push on Green」について話します。私は、自動テストの正常な実行に基づく継続的デリバリーの実践であり、おそらくライブ環境への展開であると信じています。 「Push on Green」とは具体的には何ですか、それを適用する意味は何ですか？
1
Travis-CIをコアPHPプロジェクトと統合する際の問題[終了]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、 DevOps Stack Exchangeのトピックとなるようにします。 3年前休業。 コアPHPでコード化されたプロジェクトをTravis-CIと統合しようとしていますが、常に失敗します。 Travisは、プロジェクトにファイルが1つしかない場合でもエラーを報告します。 PHPファイルコード： <?php phpinfo(); ?> .travis.yml ファイルコード language: php php: - '5.4' - '5.5' - '5.6' - '7.0' - '7.1' - hhvm - nightly
1
Elastic BeanstalkはエンタープライズグレードのCDに適していますか？
私はJenkinsを使用してマイクロサービスを構築し、Elastic Beanstalkにデプロイしているプロジェクトで作業しています。統合ブランチをテスト環境にデプロイし、ブランチをステージング環境にリリースしてから、最終的なマスタービルドを本番環境にデプロイします。私はこの方法でそれを行うことにいくつかの懸念があります。最初に、環境ごとにプロジェクトごとに1つのビルドのマトリックスが作成され、作業が重複することを意味します。2つ目は、ステージングで検証されたものと同じビルドアーティファクトを本番環境にデプロイしないことです。 私はBeanstalkを放棄して、デプロイメントにChefのようなものを使用してプレーンなASGに移行する傾向があります。これにより、プロジェクトごとに1つのビルドが作成され、ビルドアーティファクトが生成されます。ステージングで承認されたプロダクションに同じアーティファクトをデプロイできます。ただし、移行の前払いコストはさほど重要ではありません。より信頼性が高く、管理が容易なCI / CDを可能にするBeanstalkをよりよく使用する方法はありますか？ 注：同じビルドアーティファクトをプロモートすることはまさに私がやりたいことですが、ドキュメントからはそれを行う明確な方法がわかりません。アプリソースからEBにデプロイする方法について説明していますが、既存のバージョンを別の環境に昇格させる方法については説明していません。EB自体で使用できる場合、Jenkins EBデプロイメントプラグインに制限があり、それが特にJenkinsで実行できないようになっている可能性がありますが、その方法はまったくわかりません。
3
Dockerタグのバージョン管理のベストプラクティスは何ですか？
私は最近、gitコミット時にdockerイメージを構築するためにCIサーバーを接続しました。 ビルドされるコンテナは約8種類あり、それぞれに独自の言語/フレームワークがあります。一部はnodeであり、package.jsonを持っています。その他は、セマンティックバージョン情報を含まないpythonサービスです。 私の質問は、タグを作成する方法ではなく、タグの値を作成することです。 各タグが特定の画像の一意のセマンティックバージョン番号を持っていることを確認するにはどうすればよいですか？ビルドバージョンの追跡/増分の権限を持つのは誰ですか？
5
ブランチの品質レベルの低下を保証するCIツールはありますか？
従来、CIシステムは、変更がすでにコミットされているコードベースでQA検証を実行し、リグレッションを監視して人間の介入の通知を送信することにより、統合ブランチの品質レベルの監視のみを実行します。 しかし、これらのリグレッションが検出された場合、少なくともそれぞれのQA検証が開始されてからブランチはすでに問題を抱えており、すべての原因が特定されて修復がコミットされ、新しいQA検証が行われるまで、そのような状態が続きます（またはさらに悪化します！）ブランチの品質レベルが復元されたことを確認します。この間、ブランチは通常の開発のためにブロックされたと見なすことができます。 このようなリグレッションの発生を実際に防ぐことができるCIツールはありますか？これは、コミット前の QA検証を実行し、それぞれのコミットで更新されたコードベースがそれらのコミット前のQA検証にも合格する場合にのみコミットを許可するため、最小を保証しますブランチの品質レベル？ 更新：それぞれの回帰を検出できるように適切なカバレッジを備えた適切な自動QA検証がCIツールによる呼び出しに利用可能であることが前提です。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.