Blue Oceanを用いて作る初めてのパイプライン | CloudBees|テクマトリックス
始めに Jenkins 2.0からパイプラインが、そしてJenkins 2.7からはBlue Oceanプラグインが利用可能となりました。今回はこれらのプラグインを取り上げます。 対象は以下の方々を想定しています。 Jenkinsは使ったことがあるが、1.6系のJenkinsまでで止まっている。 パイプラインに興味はあるが、敷居を高く感じている。 画面ショットを交え、実際に手を動かしながら実行できる内容となっていますので、実際にJenkinsを操作しパイプラインとBlue Oceanの理解を深めていただけると幸いです。 パイプラインとは 従来Jenkinsはフリースタイルジョブでジョブを定義していました。ただフリースタイルジョブでは、例えば条件ロジックを組めなかったり、ジョブの途中で停止してしまった場合に最初から始めなければならなかったりと現実的にCI/CDを実現するには多くの制約がありま
Jenkinsfile、書いてますか？ | GREE Engineering
インフラの駒崎です。Jenkins の Pipeline スクリプトについてのお話です。 早速ですが Jenkins の Pipeline スクリプト、使われていますでしょうか。 もしかしたら以前ちょっと書いていたけどやめてしまったとか、従来の GUI 設定のほうが楽だ、となんとなく敬遠してしまっている方もいるのではないでしょうか。 私が実際そうだったのですが、最近になってやっと Jenkinsfile - Pipeline スクリプトが身近に感じられてきましたので、現状の簡単なまとめを書いてみたいと思います。少しでも似た状況の方へのヒントやきっかけになれば幸いです。 Pipeline スクリプトは難しい？ 私は正直、2016年に Jenkins 2 の目玉機能として Pipeline が出た当初は、とっつきにくい…わからん…と思っておりました。Jenkins を上っ面でなんとなく使ってい
GitHub - jenkinsci/configuration-as-code-plugin: Jenkins Configuration as Code Plugin
Setting up Jenkins is a complex process, as both Jenkins and its plugins require some tuning and configuration, with dozens of parameters to set within the web UI manage section. Experienced Jenkins users rely on groovy init scripts to customize Jenkins and enforce the desired state. Those scripts directly invoke Jenkins API and, as such, can do everything (at your own risk). But they also require
Jenkinsfileの書き方 - Plan 9とGo言語のブログ
この記事はQiitaで公開されていました ほとんど情報がなかったので調べながら書いたメモ。基本的に、公式情報が最もまとまっている。 Using a Jenkinsfile Pipeline Syntax Pipeline Steps Reference Jenkins Job DSL API また、古い情報らしいけど、現状こちらにしか書かれていない項目もある。 pipeline-model-definition-plugin Wiki Declarative Pipelineの1.2.8から、ジェネレータが追加されたようです。 The new things arriving in Declarative Pipeline! 基本 現状のJenkinsfileは2通り書き方があって、pipelineがルートになっている場合はDeclarative Pipelineという。この場合は、Groo
Jenkinsfileの書き方 (Jenkins Pipeline) - Qiita
まずはじめに つい先日、はじめてjenkins pipelineのためのJenkinsfileを作成し、PHPアプリケーションのワンクリックデプロイを実現しました。今回は振り返りの意味も込めて、その際に事前に知っておくと良かった点をまとめていきます。これから、Pipelineを構築したい方は参考にしてみてください。 環境は以下の通りです。 CentOS: 7.3.1611 Jenkins Version: 2.73.2 私の場合は、Pipelineを作成する前にRubyで書かれたCapistranoというデプロイツールでリリース用のスクリプトをすでに構築・運用済みでした。慣れてしまえば十分な環境でしたが、毎回コマンドを叩く手間と増加するチームメンバーへの共有コストを考えるとよりシンプルな手順が必要だと感じてきたため、Jenkinsへの移行を決断しました。 移行プロセスとして、ゼロからCap
具体例から学ぶJenkinsの設定 - Qiita
はじめに 自分のプロジェクトで回している自動テストに関するジョブについて簡単に説明します。 体系的な話は本を読んでもらうとして、ここでは個別具体的な話だけします。 jenkinsの設定の見方 プロジェクト名と説明欄 そのままなので特に言うこともない。 強いていうなら、説明は正しく書きましょう。 ※キャプチャの説明文をもうちょっと正確に書くなら「15分毎に開発ブランチをチェックして変更があれば実行する」かな。 古いビルドの破棄 これはビルド実施完了時に、「14日以前」もしくは「15件目を超える」ジョブ履歴を消す設定になっています。 ビルドの実施完了時に削除処理が走るので、月に1度しか動かなさいジョブなら、ジョブを実行するまで前回分（1ヶ月前）のジョブ履歴は残っています。 ソースコード管理 Gitのリポジトリを指定して持ってきています。 まぁ要はcloneないしはpullするリポジトリ。 ちな
Jenkinsfile を書く前に知っておくべきこと (セキュリティ制約編) - あらしおブログ
Jenkins のパイプラインスクリプト(Jenkinsfile)は groovy ベースですが、 セキュリティや機能上の理由から様々な制約があります。 特別複雑な処理に制約があるというわけでもなく、groovy なら誰もが使いたくなるリストやマップのクロージャ処理が使えなかったり、 Serializable でないオブジェクトを扱えなかったりと、思った以上に使いにくいところがあるようです。 今回はセキュリティ上の制約についてわかったことを書きたいと思います。 対象読者は、Jenkins 公式の Overview を一通り読んでこれから自分でスクリプトを書こうと思っている方、 書いてみたけど RejectedAccessException 例外が発生して先に進めない方などです。 セキュリティ上の制約 誰でも任意のコードをパイプラインスクリプトで実行できるのはさすがにセキュリティ上の問題があ
Kubernetes環境に特化したCI/CDツール「Jenkins X」を試してみる | さくらのナレッジ
広く使われている継続的インテグレーション（CI）/継続的デリバリ（CD）ツールの1つに「Jenkins」がある。このJenkinsの開発チームが、Kubernetesに特化したCI/CDツール「Jenkins X」を発表した。今回はこのJenkins Xの特徴やインストール、基本的な使い方を紹介する。 昨今ではソフトウェア開発を迅速に進めるために「継続的インテグレーション（CI）」と呼ばれる手法が広く採用されている。CIはバージョン管理システムなどと組み合わせて使われるのが一般的で、たとえばバージョン管理システムへのコミットをトリガーとして自動的にビルドやテスト、パッケージ作成を実行する仕組みなどを構築できる。また、最近では「継続的デリバリ（CD）」という手法も使われる。CDはCIと似ているが、運用環境へのデプロイまでも自動で行うという仕組みだ。 CIツールとして著名なものの1つに、以前紹
JenkinsとKubernetesでCIパイプラインを構築 - Qiita
JenkinsとKubernetesを連携させてCIパイプラインを構築する時に、一番悩むの点は、いろいろな方法があるために、何を選択して良いか解らない。そして、実際に実装を進めると、様々な問題が発覚して、時間がかかってしまうことがある。 Jenkinsのプラグインで、Dockerに関するものだけでも約20種類、Kubernetesの関係するもので 約17種類もある。しかも、これらが問題なく動作するという保証も無い。筆者が経験したケースでは、資料が作られた時期から時間が経過すると共にプラグインが更新され、新たな問題が生じてしまい、動作しなくなっているなどがあった。そして、ドキュメントは、Jenkinsに詳しいエンジニア向けに書かれているために、普段触り慣れないJenkins初心者には難解な内容となっていることもある。 そして、Kubernetes上でJenkinsを動作させる場合にも問題が多
もう 2018 年だけど, Jenkins + Docker + itamae + Serverspec でインフラ CI っぽいことをやってるのでメモ - ようへいの日々精進XP
やってること メモ Jenkins を動かす環境 Docker イメージ itamae レシピ Serverspec テスト Jenkins の準備 プラグイン Docker 周り ジョブ infra-itamae の設定 infra-serverspec の設定 動いてる図 Build Pipeline ログ 以上 やってること 今更かもしれないけど, ギョームで以下のようなことをやって, ここ数日で運用も回ってきた気がするのでメモしておく. itamae のレシピを amazonlinux コンテナに適用 適用したコンテナに対して Serverspec でテスト 1 と 2 を Jenkins のビルドパイプラインで流す 3 が正常に終了したら, pull request を作成, 又はマージ master ブランチのレシピをサーバーに手動で適用 Jenkins のポテンシャルと it
CIマニアから見た各種CIツールの使い所 - くりにっき
社内外でちょいちょい聞かれるのでメモ。 前置き GitHubを使ってる場合 ライブラリを作ってる場合 Travis CIを選択する理由 2020/4/21追記 Travis CIを選択しない理由 アプリを作ってる場合 CircleCIとWerckerの共通点 CircleCIとWerckerの機能差異 GitLabを使ってる場合 GitLab CIの優位点 Jenkinsなどを使った方がいい場合 追記：2018/12/8 前置き 100%自分の主観なので偏ってます SaaSかオンプレならSaaS派。（自分でサーバの面倒身たくない） 自分が使ったことがないものは紹介していません 今回紹介してるTravis CI, CircleCI, Wercker, GitLab CI, Jenkinsに関しては仕事や趣味で各3〜4年くらいは使ってるはず GitHubを使ってる場合 ライブラリを作ってる場合
Jenkinsだけじゃない、DeNAが無名ツールを選択した理由
現在のシステム開発では、リリースサイクルの短期化が欠かせない。激しく変化するビジネス要求に対応しなければならないからだ。そのニーズに応えるツールがCI（継続的インテグレーション）ツールである。CIとは、ソースコードのコンパイル/ビルド/テスト/品質検査などの処理を自動化し、繰り返し何度も実行する手法。CIツールはこのような手法を手助けするもので、短いサイクルで繰り返しリリースし、市場の変化に素早く対応できるソフトウエア開発には必要なツールと言える。 「CIツールの細かい設定作業を省き、開発者がよりコーディングに専念できる環境を整えたかった」。ディー・エヌ・エー（DeNA）で新規アプリ開発プロジェクトに携わるコマース＆インキュベーション事業本部の春山誠氏は、ハンガリーのビットライズが提供するCIツール「Bitrise」の導入理由をこのように話す。 CIツールの定番といえば、オープンソースソフ
無限にスケールする上に自律的なJenkinsに見る夢~AWS篇~ / Dream of autonomous and infinite scalable Jenkins with AWS - Speaker Deck
Kyotoなんか #4の資料です
Introducing Jenkins X: a CI/CD solution for modern cloud applications on Kubernetes
use of immutable container images for distributing software which are smaller, easier to work with and lead to cheaper infrastructure costs than VMs alone (approx 20% less on average) Kubernetes has become the defacto way of installing, upgrading, operating and managing containers at scale on any public or hybrid cloud 2018 is the year all the major public clouds, operating system vendors and PaaS
3倍どころか10倍速い！ Jenkins のビルドを高速化して、シャアを超えた男 | 株式会社ヌーラボ(Nulab inc.)
実はガンダムを見たことがないので、時々社内のガンダムトークについていけないことがあります、中村です。今日は、 Jenkins のビルドを高速化し、リリースまでの時間を大幅に短縮した、改善策をご紹介します。全体で2~3倍程度、一部処理では何と10倍以上もビルドを高速化できました。 改善策1 : push 型デプロイから pull 型デプロイへ 改善策2 : テストケースを自動分割して、よりアグレッシブに並列実行 全体のリリース時間に対する改善結果 ビルド時間の可視化 改善策1 : push 型デプロイから pull 型デプロイへ まずはデプロイ時の方式を、push型デプロイからpull型デプロイに変更した改善策を説明します。ここで、push型デプロイは中央サーバからデプロイ用ファイルを転送する方式で、pull 型デプロイは各サーバがファイルを取得する方式とします。 各フェーズの構成は、下図の
Jenkinsジョブ（ビルド～テスト）をDockerコンテナ上で実行する ～Docker Pipeline Pluginを使ってみる～ - SIerだけど技術やりたいブログ
ビルドやテストなどの一連の作業をJenkinsで自動実行することを考える。 通常これらのジョブはJenkinsのmasterやslaveで実行されることになり、ビルドに必要な環境構築（例えばjavaのインストールやmavenのインストール）はJenkinsのmasterやslaveに対して、事前に行うことになる。そして一度環境構築したサーバは長いこと使われる。 そうなると、同一サーバで複数バージョンのjavaを入れる苦労をしたりディストリビューションの差に基づくLinuxコマンドのあるなしに翻弄されたり、ローカルにしかないファイルを参照してそのうちジョブが動かなくなったりする。 これを解決するための手段としてビルド〜テストをDockerコンテナ上で実行しようという例は多くみられ、以下の記事が導入検討の参考になる。 www.buildinsider.net www.slideshare.ne
【Jenkinsを使った自動テスト環境を作る】Dockerコンテナを使って自動ビルドを実行する | OSDN Magazine
継続的インテグレーション（CI）ツールとして有名なJenkinsは、ソフトウェア開発におけるテストやビルドと言った作業を自動化するツールだ。後編となる今回は、Dockerを使ってコンテナ内に構築したビルド環境をJenkinsから利用する例を紹介する。 Jenkinsの「マスター/スレーブ」機能 前回記事では、Jenkinsをインストールしたサーバー内でソフトウェアのビルドやテストを行うことを前提に環境を構築していった。Jenkinsをインストールしたサーバーと、対象とするソフトウェアのビルド/実行環境が同じで構わなければこれで問題はないが、たとえばそれぞれビルド/実行環境が異なる複数のソフトウェアをJenkinsで管理したい場合、このやり方では複数台のサーバーを用意しなければならない。 Jenkinsではこういった問題を解決するため、Jenkinsがインストールされたサーバーとは異なる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kubernetes時代のCI/CD Jenkins Xとは?-前編
Unity × Jenkinsで複数バージョン書き出しと動的なインポート/ Unity × Jenkins Multiple Build And Dynamic Import
JenkinsのUXをシンプルかつビジュアルにする「Blue Ocean」バージョン1.0がリリース。パイプラインの設定や実行状況などをGUIで実現
