（この記事は、CloudBees社 Blog 「Opinionated Kubernetes and Jenkins X」2018年3月18日 Michael Neale 投稿の翻訳記事です。）
先日、あらゆるクラウドプラットフォームがKubernetesに集結し、開発者も同様だという記事を書きました。とてもエキサイティングな時期を迎えていますが、反面、多くの人にとって問題となるのは、アプリケーションをどうビルドしてデプロイするかについて、まだまっさらの大きな白紙であることです。これは空白、無であり、無限の可能性を秘めたキャンバスです。
問題は、想像がつくと思いますが、何も描かれていないキャンバスでゼロから始めることが本当に好きな人、また始められる人はほとんどいないということです。私自身も、何か既にあるものから作業を開始し、解決に向かって試行を繰り返すか、あるいは何か指針となるレールがあるほうが良いと感じます。
ここでJenkins Xプロジェクトを紹介したいと思います。Jenkins Xは、クラウドネイティブアプリケーションを開発するためのKubernetesネイティブな継続的インテグレーション（CI)および継続的デリバリー（CD)プラットフォームで、つい最近James Strachanが発起人となってJenkins Enhancement Proposalとして立ち上げられました。
理解するべきことはたくさんありますが、核心を言えば、Jenkins X とは、私が前回のブログ記事で述べたようなことをすべて学ぶことなく、ネイティブにKubernetesを利用して継続的デリバリーを実践するための仕組みを提供するオープンソースです。この後、Jenkins Xとは何か、そしてJenkins Xが開発者にとって重要である理由を説明します。jenkins-devメーリングリストでのある発言に従って表現すれば、「私たちは（JenkinsとKubernetesの）2つをワイヤーと紐でくっつけた」のであり、Jenkins Xは継続的デリバリーとKubernetesの利用を簡単にすることを目指しています。
まず、重要な要素として、ロゴを見てみましょう。
航海関連のテーマがちらついているのがわかります（それからKubernetesも）。Jeknkins Xと名づけられてはいますが、Jenkins以外の要素も多数あります。
決定を肩代わり
Jenkins Xに初めて触れるとき使用することになるのが、便利で洗練されたコマンドラインです（jxという名前のインストール可能なネイティブバイナリですが、これをどのように発音するかについてはまだ議論の最中です）。では、ツアー（それとも航海？）に出発しましょう。
> jx import my-app
既存のプロジェクトがある場合、コマンドはプロジェクトのタイプを検出し、パイプライン（およびHelm ChartsなどのKubernetes関連ファイル）を構築してプロジェクトに追加し、GitHubにセットアップを行い、WebHookなどもろもろを設定し、プロジェクトをビルド（パイプラインを実行）し、「ステージング」環境にバージョンをデプロイします。
結果に問題がなさそうであれば、バージョンを運用環境ににプロモートできます。
> jx promote —env production —version 1.0.1 my-app
運用で問題が発生した場合は、アプリを任意のバージョンにロールバックすることができます（バージョン番号も自動的に作成されています）。
> jx promote —env production —version 1.0.0 my-app > jx get apps # list versions
環境は、継続的デリバリーを実践しているWeb開発者にとっては、すでにおなじみのコンセプトです。デフォルトのままのJenkins Xでは、dev、staging、productionの3つの環境が作成されますが、環境の数は任意に変更できます。環境には、環境へのプロモートに関するルールがあります（また、独自の拡張可能なパイプラインもありますが、最初はデフォルトのまま利用できます）。
Spring Bootマイクロサービスアプリを作成することもできます。
> jx create spring
いくつかの質問に答えると、必要なものがすべてセットアップされます。
アプリケーションに加えた変更はすべて自動的にビルドされ、ビルドに問題がなければステージング環境に移行します。GitHubを使用している場合は、円滑な処理のためにWebHookが設定されます。
既成のアプリから始めたい人のために「クイックスタート」があります。
> jx create quickstart
「クイックスタート」は随時拡張されているスターターアプリのセットを基にしており、さまざまな言語と技術が使われています。
変更を確認するためのレビューアプリ：プルリクエストごとにビルド/テストが行われ、一時的な環境で「レビュー アプリ」が利用できるようになります。つまり、提案された各変更は、デフォルトのブランチ（マスター）に入れる前に、（一時的な）環境を作成して、そこで試すことができます。GitHubでは、これはプルリクエストのコメントとして表示されます。
プロジェクトタイプの検出
ご覧のとおり、これまでのところ、パイプラインの手動による作成や編集、スクリプトの記述や設定は必要なく、単にアプリケーションをインポート、または作成するだけです。これはDraft の「packs」（Azureから生まれた便利なプロジェクト）によって実現されています。最終的には、プロジェクトリポジトリにJenkinsfileが作成されます。いずれJenkinsfileを編集することになるかもしれませんし、そのままでも十分かもしれません。Jenkinsはユーザーに自由なやり方を許すことで有名ですが、Jenkins Xは特定の方法を強制します（ただし、拡張やカスタマイズが可能です）。
環境へのデプロイまたはプロモート
デプロイメントは、変更がプッシュされたとき、またはバージョンがプロモートされたとき、背後のパイプラインによって行われます。必要がないかぎり、Kubernetesと直接対話することはありません。面倒な処理は、Helmと呼ばれるツールがやってくれます。Helmを使用して、アプリケーションのパッケージ化、インストール、アップグレードが行われます。
航海のテーマがさらに顕著に
環境周りには、最初はわかりにくい仕掛けがまだあります。チームの各環境は、背後ではGitリポジトリによって表されます。コードとしての設定（Configuration as code）は、最近では定番のベストプラクティスであり、デプロイメントの追跡や開始にこれを利用しない手はありません。私はまた、以前の記事で、Kubernetesがどれほど宣言的であるかについて触れました。目的のシステム状態に関するすべての設定を1つのリポジトリで維持するのに、Kubernetesは最適です。
プロモーションは、実際には環境ごとのリポジトリへのプルリクエストです。このリポジトリは、自動的に作られ、管理されます（メインのアプリケーションコードリポジトリとは別に維持されています）。意識する必要はありませんが、必要に応じてこのリポジトリを拡張することができます。それぞれの環境リポジトリに異なるアクセスルールが設定されたり、リポジトリごとに別のチームによって制御される場合があります（別のクラスターにデプロイされる場合もあります）。これは「GitOps」と呼ばれることもあります。私が最初にこのコンセプトについて見たのはWeaveWorksのブログでした。
これを図で説明します。
パイプラインは中心で分割されています。左側には、比較的なじみのある継続的インテグレーションのパイプラインがあります。これはプレリリース版のプルリクエストで実行され、全てのテスト（自動化されたテストあるいは手動によるレビュー）が行われます。このパイプラインは、アプリケーションリポジトリの構成（ブランチ、プルリクエストなど）に基づきます。
右側は継続的デリバリーのパイプラインです。新しいリリースを使ってアプリケーションを更新する準備が整うと、このパイプラインが開始します。これは背後でKubernetesの状態を制御する”GitOps”リポジトリです。こちら側でのプロモーションはプルリクエストであり、次にステージングリポジトリから運用リポジトリへのマージです。
インストール
jxコマンドラインには、Kubernetesクラスターへのインストールを行うjx installコマンドがあります。
手始めとしておすすめするのは、Googleの優れたGKEサービスを使用することです。
> jx create cluster gke
いくつかの質問に答えると、Jenkins Xのために用意されたクラスターにすべてがセットアップされます（これは推奨オプションです）。Jenkins XはKubernetesクラスター上でサービスとして実行されます。
> jx install
Jenkins XはKubernetesクラスターで動作するように設計されています（既にクラスターが存在する場合は、可能であればJenkins X専用のクラスターを用意することをお勧めします）。今後、Amazon EKSのサポートが予定されています（ほぼテスト段階に来ています）。サービスはベータ版/早期アクセスであり、まだ開発中です。Microsoft AzuresのAKSサービスについても同様です。
ところでJenkinsはどこに？
良い質問をありがとうございます。実は、Jenkinsはバックグラウンドにあります。ここまで見てきたように、Jenkinsとの直接的なやり取りはありませんでしたが、Jenkinsは確かに存在し、パイプラインを実行してそれぞれのリポジトリの継続的インテグレーションと継続的デリバリーを実現しているほか、Kubernetesと連携して処理をオーケストレーションしています。
jx get pipelinesを実行すると、Jenkins Xとの連携の一部としてセットアップされているさまざまなパイプラインのURLが表示されます。
ちなみに、 James Strachanがjenkins.ioで書いているブログがあります。そこではJenkins Xプロジェクトについて詳しく解説されています。この記事を読み終えたら、James Strachanのブログを眺めてみてください。また、プロジェクトに参加する方法も案内されています。
コマンドラインで他に何ができますか？
いろいろです。jxコマンドラインにはヘルプが組み込まれています。
jx open
– ブラウザーでアプリ、サービス、パイプラインを開く
jx activity
– 成果物がどのように現在の場所に移動したか、履歴を表示
jx help
jx get environments
– 環境の一覧を表示
jx get apps
– アプリケーションの状態、どのバージョンがどの環境にあるかを表示
次のステップ
これはさらにいろいろです。非常に便利な部品やサービスもたくさん用意されていますが、とりあえずjenkins-x.ioをざっと眺めてみるのが一番です。
このプロジェクトは間違いなく初期段階です（まだJEPでしかないのです）。日々多くのことが起こっています。slack、IRC、Issues、またはメールで意見交換したい場合は、 Jenkins Xコミュニティをチェックしてください。また、Jenkins Enhancement Proposalのドキュメントを読んでください。
CloudBeesは最近、Kubernetesをはじめ、その他多くの重要なクラウドネイティブテクノロジーを含むCloud Native Computing Foundationに加わりました。継続的インテグレーション、継続的デリバリー、そしてKubernetesの周りでコミュニティが成長していくのを見るのは興味深いことでしょう。