cds
0.54.1
CDSは、GO（Lang）で記述されたエンタープライズグレードの連続配信およびDevOpsオートメーションプラットフォームです。
このプロジェクトは積極的な開発中です
ドキュメント
CDSは、複雑なワークフローを構築し、それらを実行し、必要に応じてログを掘ることができる直感的なUIを提供します。
CDS UIでワークフローを作成および実行します。
CDSCTLはCDSコマンドラインです - すべてをスクリプト化できます。CDSCTLは、ブラウザを開くことなくプロジェクトやワークフローを閲覧するためのcdsctl shellなどのクールなコマンドも提供します。
すべてのCDSCTLコマンドを参照してください
CDSコマンドラインを使用してコードとしてワークフローを作成します。
Docker-Composeはあなたの友人です。ReadyToTutorialsを参照してください
CI/CDツールのほとんどは、パイプライン内のジョブで再生されます。 CDSは、 CDS Workflowsという名前の新しいコンセプトを紹介します。 CDSワークフローを使用すると、トリガーでパイプラインをチェーンできます。パイプラインは、1つまたは複数の同時ジョブを含む順次段階で構成されています。
はい！ CDSは2015年@OVHから生産に使用されており、年間7m以上のCDS労働者を発売します。 https://github.com/ovh/cds/releasesで公式リリースをインストールできます
CDSは、生産活動を監視および測定するために必要なすべてを提供します（ログ、メトリック、監視）
すべてのデータはデータベースに保存されます - ファイルシステムには何もありません。データベースを定期的にバックアップするだけで、安全になります。
コアチームはGitHubで利用できます
複数のジョブを同時に実行しながら、それらの間で隔離を維持する能力。パイプライン内のステージとジョブに関するドキュメントを参照してください。パイプラインは、コンテキスト、0または1アプリケーション、0または1の環境で開始されます。
ワークフローにより、パイプラインをチェーンできます。これはCDSの重要な機能です。 1つ以上のパイプライン、結合またはフォークと一緒にリンクできるパイプラインを使用してワークフローを作成できます。
ワークフロービルダーが1つだけで、マイクロサービススタック全体を展開することを想像できます。同じパイプラインをワークフローで数回使用できます。アプリケーションまたは環境を関連付けることができます。何百ものアプリケーションがある場合でも、展開パイプラインと1つのビルドパイプラインのみが維持されます。
ワークフローテンプレートを使用すると、複数のチームでワークフローを共有および再利用できます。すべてのユーザーは、ワークフローテンプレートを作成し、コードまたはUIから維持し、単一のアクションでワークフローのセットをバルク更新できます。
会社として、事前定義されたワークフローのカタログを提供して、すべてのチームでテストと展開の実践を標準化できるようにできます。
これにより、テンプレートがスケーラブルな集中管理を可能にするため、メンテナンスの取り組みも削減されます。
Web UIですべてを構成できます。複雑なユースケースがある場合でも、通常、ワークフローをグラフィカルに作成する方が簡単です。
コードとしてのパイプラインは、CI / CDツールのよく知られた概念です。 CDはさらに一歩進んで、コードとしてワークフローを提供します。これは、ワークフロー（ +パイプライン、 +アプリケーション、 +環境）のYAML構成ファイルを使用してGit-Pushingによって行われます。これは、マスターブランチの変更を統合する前に、開発ブランチで新しいワークフローをテストできるため、特に便利です。
UIでワークフローを変更することもできます。必要に応じて、YAMLファイルをUIで直接編集して構成を変更することもできます。これは、コードとしてのワークフロー機能を使用する方法を学ぶための優れた方法です。
ブランチパターンに基づいてビルドを起動する機能。これにより、たとえば、dev/*ブランチを「ステージング」に展開し、マスターブランチを「prod」に展開できます。
CDSのデフォルトの動作は、すべてのGITコミットでワークフロー全体を起動することであることに注意してください。この動作は、「実行条件」を使用して変更できます。
最も人気のあるGITベースの製品との2方向の統合。
CDSは、Github、Gitlab、Bitbucket Server、およびGerritをネイティブにサポートしています。 Git RepoとCDSの間のリンクは、CDSアプリケーションを介して行われます。1GitRepository == A CDSアプリケーション。この統合を通じて、CDはコミットのビルドステータス、つまり構築、成功、または失敗を推進します。
CDSは、単一のワークフロー内でさまざまなGitリポジトリからクローンを作成する可能性があります。 CDSワークフローには、いくつかの異なるアプリケーションが含まれます。または、GITリポジトリと接続したくない場合はありません。
仕事をサポートするためには、短命サービス（データベース、Webサーバーなど）を開始する能力。これは、コードをテストする際に特に便利です。
CDSでは、これらのサービスはサービスの前提条件と呼ばれます。対応するDockerイメージを指定し、PARAMを実行するだけです。
簡単な例を取ります：アプリケーションを含むDocker画像を構築するパイプラインがあります。アプリケーションには、動作するためにRedisとPostgreSQLが必要です。 CDSジョブでは、Redis、PostgreSQL、およびアプリケーションの3つの前提条件サービスを入力できます。 CDは、サービス間でプライベートネットワークを作成し、相互に通信できるようにします。したがって、CDSジョブは、実際のデータベースと実際のキャッシュから始まるアプリケーションで統合テストを実行できます。
https：//ovh.github.io/cds/docs/concepts/requirement/requirement_service/
リモートキャッシュは、開発者チームおよび/または継続的な統合（CI）システムによって使用され、ビルド出力を共有します。ビルドが再現可能な場合、あるマシンからの出力を別のマシンで安全に再利用できるため、ビルドを大幅に高速にすることができます
ドキュメント：https：//ovh.github.io/cds/docs/components/worker/cache/
エンタープライズグレードのプラットフォームとして、CDSはイベントバスで幅広い内部イベント（たとえばビルドが完成）を送信できます。このイベントフローは、他のサービス（レポート、通知など）に与えることができます。
手動で、またはGit Pushesを使用して、またはスケジューラを介して、またはWebhookを介してワークフローを起動する機能。上記に加えて、イベントバス（KafkaまたはRabbitmq）を使用してCDをトリガーすることもできます。
隔離されたアクセス権を備えた安全な方法で複数の環境（dev/prod/staging）を管理する能力。実際には、環境はワークフロー内で使用できる一連の変数です。
CDSを使用すると、プレプロダクション環境で展開パイプラインを使用し、生産環境で同じ展開パイプラインを使用できます。生産に展開する機能は、事前に確立されたユーザーグループに限定できます。
ユーザーは自由にグループを作成し、グループ内のユーザーを管理できます。グループは、プロジェクトとワークフローを読み、書き、実行する権利を持つことができます。必要に応じて、一部のパイプラインの実行を一部のグループに制限することもできます。
CDSをCI / CDツールとして使用する場合、おそらくアーティファクトを構築しているでしょう。 CDSジョブは互いに分離されていますが、アーティファクトのアップロードとアーティファクトのダウンロードアクションを使用して、あるジョブから別のジョブにアーティファクトを渡すことができます。 CDSジョブの終わりに、すべてのファイルが労働者から削除されます。アーティファクトを持続させるために、CDはSwiftストレージまたは特定のファイルシステムを使用できます（ただし推奨されません）。
CDSは、ビルド中に検出された単体テストと脆弱性の結果を明確に示しています。
CDSプロジェクトはテナントのようなものです。すべてのユーザーがCDSプロジェクトを作成できます。このプロジェクトは、アプリケーション、環境、パイプライン、そしてもちろんワークフローをまとめます。
CDSプロジェクトは互いに隔離されていますが、同じグループは、必要に応じて複数のプロジェクトにアクセス権を持つ場合があります。
労働者モデルは、労働者の実行コンテキストです。たとえば、Golang v1.11.5を必要とするジョブを実行する必要があるとします。 CDSでは、バージョン1.11.5のGOを含むGOワーカーモデルを作成するだけです。ワーカーモデルは、Dockerイメージ、OpenStack画像、またはVSphere画像です。 CDS管理者は共有ワーカーモデルを提供できますが、ユーザーは必要に応じて独自のテンプレートワーカーを作成できます。
CDSプロジェクトでは、OpenStack、Kubernetesなどの統合を追加できます。これにより、ワークフロー内の機能が提供されます。たとえば、Kubernetesの統合を使用すると、独自のクラスターをCDSプロジェクトに追加するため、Deploy Applicationアクションを使用して、必要に応じてヘルム形式で新しく構築されたアプリケーションをヘルム形式で展開できます。もちろん、独自の統合を開発できます。
前のポイントを読んだ後、あなたは理解しました：セルフサービスはどこにでもあります。すべてのユーザーは、プロジェクト/ワークフロー/ワーカーモデル/ワークフローテンプレート/アクションを作成し、完全に孤立した環境でジョブを実行できます。 CDSプロジェクトはビルダーであり、統合を追加できます。これにより、会社全体にCDSのインスタンスを1つだけ使用できます。
UIでできることはすべて、「cdsctl」という名前のコマンドラインインターフェイス（CLI）を介して利用できます。 CDSCTLは、すべてのOSで利用できます：Darwin、FreeBSD、Linux、OpenBSD ... CDSCTLは、ワークフローを作成、起動、エクスポート、インポート、CDSを監視し、プロジェクトとワークフローをナビゲートできます。 CDSまたはリポジトリマネージャーのUIにアクセスして、コミットのステータスを確認する必要はありません。Git git push && cdsctl workflow --trackコマンドラインにワークフローを表示します。
さらに高度な自動化のニーズ、またはCDを照会するアプリケーションを開発したいという願望はありますか？ REST APIとSDKを使用すると、ソフトウェアを簡単に開発できます。
CDSは2016年10月からオープンソースです。会社や自宅に自由にインストールできます。一部のチュートリアルは、CD、Docker-Compose、バイナリをインストールするのに役立ちます。
高可用性は、CI / CDツールにとって非常に重要なポイントです。 CDSはステートレスであり、ファイルシステムには何も保存されていません。これにより、ロードバランサーの背後にいくつかのCDS APIを起動することができます。したがって、CDのAPIをニーズに合わせて拡張できます。また、ユーザーに影響を与えることなく、1日でCDのアップグレードを許可します。 Production @OVHでは、ユーザーに影響を与えたり、CDSワーカーを停止することなく、CDを1日に数回更新できます。継続的配信ツールの更新中に作業を停止するようにユーザーに依頼するのは皮肉ですね。 ;-)
CDSは監視データをネイティブに公開します。インスタンスプロメテウスまたはビーミウムを使用してWarp10に供給できるようになります。
CDSジョブはステップで構成されています。各ステップは、組み込みのタイプアクション（スクリプト、CheckoutApplication、Artifactのアップロード/ダウンロード...）です。既存のアクションを使用してアクションを作成するか、プラグインとしてアクションを開発できます。言語がGRPCをサポートする限り、すべての言語がサポートされています。
CDは言語やプラットフォームに不可知論されます。ユーザーは、Linux、Windows、FreeBSD、OS X、Raspberryでジョブを立ち上げることができます。
そのため、会社が複数のテクノロジーを使用している場合、CDは内部ソフトウェアを構築および展開するためのブロッカーではありません。
OVHでのCDの初期目的の1つ：150のアプリケーションを7分以内にコンテナとして構築および展開します。これは2015年以来現実になりました。秘密の鍵は何ですか？オンデマンドで自動スケール！
したがって、何百もの労働者モデルを持つことができ、必要に応じてCDはhatch化場を使用して労働者を起動します。
hatch化場はインキュベーターのようなものであり、CDS労働者と生命と死の権利を生み出します。
いくつかのタイプのhatch化場が利用可能です。
はい、流行語かどうかにかかわらず、マルチクラウドの自動スケールのオンデマンドはCDの現実です:-)
3-crose bsd
