2016-06-23 16 views
1

私たちはリリースと展開にJenkinsを使用しています。今はContinuous Integrationツールを使用せず、Continuous Delivery Toolを使用するように指示されています。これは何を意味し、plは何か良いオープンソースのContinuous Delivery Toolを提案します。継続的配信ツール

答えて

1

Jenkinsは、展開プロセスを自動化するための単なるツールです。手動で展開をトリガするか、継続的な配信プロセスを使用するかは、あなたに依存します。

継続的インテグレーション(CI)は、コードを共有リポジトリに1日数回統合する開発者を必要とする開発方法です。技術的には、「継続的統合ツール」というものはありません。

ジェンキンス以外にも、あなたは次のように使用することができ、他のCDツールがあります: -

  1. GoCD
  2. Travis CI
  3. Buildbot

など、誰かが継続的インテグレーションを言う

+0

アドバイスありがとう –

+0

助けがあれば、それを正解とマークしてください – hspandher

0

、それはCIがQA構築とQAサーバーへのデプロイ、ビルドが壊れていないことを確認するための新しいコードの自動ビルドなどが含まれますが、実動デプロイステップではあまり効果がありません。しかし、継続的な配信(または展開)では、「より迅速かつより頻繁に本番環境への変更の配備方法」に焦点を当てたアプローチです。つまり、それは製品やツールではなく、概念やアプローチの可能性が高いということです。あなたが言及したようにジェンキンスと、それは特にCDのために設計されていないと機能のいくつかの欠如している。しかし、Jenkins 2.0にはいくつかのCD機能があり、プロダクションのビルド/デプロイメントのパイプラインをより簡単にすることを耳にしました。 他にオープンソースのCDツール(go.cdなど)がいくつかありますが、まだ使用していません。

0

Jenkins 2.0は、ジョブをパイプラインとして拡張することができるオープンソースツールの1つです。複数のステージを定義し、各ステージでビルドからテスト、パッケージ展開からリリースに展開する配信タスクを実行します。 Jenkins 2.0へのインストールのアップグレードを検討することは間違いありません。

しかし、既存のJenkinsを使用していても、継続的にプロダクションにリリースできるように、配送パイプラインをつなぎ合わせることができます。

しかし、重要なのは、チームがこれらの変更を生産に反映させるために継続的に変更する準備ができていることです。それは文化的な問題よりもツールの問題ではありません。 1.開発者が大胆に変更を行い、本番環境で動作しないという速いフィードバックを得るのに役立つテストアセットを用意してください。 2.生産セットアップと開発者セットアップの間に差異がないようなインフラストラクチャーがあるので、(1)を効果的に達成することができます。 3.変更や要件は、他のものとは独立して完成できるようにモデル化してください。 4.各モジュールを独立して配備できるように配備の自動化をしてください。

JenkinsやJenkins 2.0や他のツールの質問は重要ですが、十分にテストされた独立したチャンクを提供する準備が整っていると思いますあなたが道に沿って歩くときに重要です。

あなたのCD旅行で幸運を祈る。

0

すべての流行語を取り除くと、継続的な配信とは、計画から制作までの変更のための最も効率的な経路を構築することです。しかし、効率的で接続されたパイプラインでは、アプリの品質の向上と不必要な再作業の削減が見られるようになります。このプロセスは、多くの自動化ツール(CI、デプロイメント、テスト、構成管理など)でサポートされていますが、使用するツールを変更することなく、エンドツーエンドのパイプラインを管理することが最も役立ちます。

CDDirector.ioは無料でお試しいただけます。オープンソースではありませんが、オープンソースや商用ツールをサポートしています。すべてのDevOpsツールをオーケストレーションし、計画からCI /ビルド、テスト/ QA、プロダクションに移行する際に、コードの可視性を提供します。また、パイプラインのエンドツーエンドのトラッキングと、ボトルネックを表示するための分析機能、および改善が必要な箇所を表示することができます。実際にあなたの旅を継続的な配達にマッピングするのに役立ちます。幸せの旅!

関連する問題