VSハッカソン倶楽部 CI勉強会で発表した資料となります。 https://vshtc.doorkeeper.jp/events/26853
VSハッカソン倶楽部 CI勉強会で発表した資料となります。 https://vshtc.doorkeeper.jp/events/26853
ビルドやテストなどの一連の作業をJenkinsで自動実行することを考える。 通常これらのジョブはJenkinsのmasterやslaveで実行されることになり、ビルドに必要な環境構築（例えばjavaのインストールやmavenのインストール）はJenkinsのmasterやslaveに対して、事前に行うことになる。そして一度環境構築したサーバは長いこと使われる。 そうなると、同一サーバで複数バージョンのjavaを入れる苦労をしたりディストリビューションの差に基づくLinuxコマンドのあるなしに翻弄されたり、ローカルにしかないファイルを参照してそのうちジョブが動かなくなったりする。 これを解決するための手段としてビルド〜テストをDockerコンテナ上で実行しようという例は多くみられ、以下の記事が導入検討の参考になる。 www.buildinsider.net www.slideshare.ne
以前のエントリ（ http://knjname.hateblo.jp/entry/2014/05/03/190842 ）で自分でJenkinsのDockerイメージを作成したりしてみましたが、 Jenkins公式でDockerイメージを配布するようになったので、それを使用したほうがいいと思います。 Github https://github.com/cloudbees/jenkins-ci.org-docker DockerHub https://registry.hub.docker.com/_/jenkins/ 普通に使うだけなら、下記のようにすればいいだけですが、 docker run -p 8080:8080 jenkins これだと何も細かいことを設定できていないので、いくつか補足。 Dockerイメージ内のJenkinsのバージョンについて 永続化ディレクトリ(JENKINS_
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「開発者（個人）のための」としているのは、別に自分でやっても良いんだけど Jenkins に任せられるなら任せたい、くらいのモチベーションを表現したつもりです。 ここでは、スレーブの作り方と使い方を簡単にまとめてみました。 環境 Ubuntu 14.04 LTS Jenkins 1.580, 1.582 途中から 1.582 に Upgrade しました スレーブの設定方法 まずはスレーブを作ってみる とりあえず作るなら、localhost だけで十分です。 スレーブの新規作成 スレーブの設定 赤枠で囲んでいる部分が、手を加え
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
改善策1 : push 型デプロイから pull 型デプロイへ まずはデプロイ時の方式を、push型デプロイからpull型デプロイに変更した改善策を説明します。ここで、push型デプロイは中央サーバからデプロイ用ファイルを転送する方式で、pull 型デプロイは各サーバがファイルを取得する方式とします。 各フェーズの構成は、下図のようになっています。 社内スレーブ + push型デプロイ 当初の構成は、社内に物理サーバを用意し、その上にJenkinsのスレーブを立てていました。そのスレーブから、WARファイルを各アプリサーバに転送するpush 型デプロイ方式を採用していたのです AWSスレーブ + push型デプロイ 社内で物理サーバを立ててメンテナンスをしていくのは、メンテナンスコストがかかります。そこで、AWS上にインスタンスを立て、さらに、Dockernizeを進めてスレーブのメンテナ
sue445 2017/03/02 GitLab Meetup Tokyo #1 自己紹介 Go Sueyoshi a.k.a sue445 株式会社ドリコム 所属 インフラストラクチャー部 社内gemを中心にアプリからインフラまでだいたいサーバサイドを浅く広く見てる 今まで作った主要なものは sue445 Advent Calendar 2016 - Qiita を参照 「ドリコムのプリキュアの人」として社内外で有名 Twitterは上級者向けのアカウントなのでフォロー厳禁 GitLab関係で作ったものをいくつかピックアップ GitLab Notifier for Google Chrome™ GitLabの通知を受け取るためのChrome拡張 Jenkins GitLab Logo Plugin JenkinsにGitLabのプロジェクトのロゴを表示 gitlab_awesome_re
Androidアプリのビルド／テストはCIでここまで変わる：グリーはいかにしてJenkinsを導入したのか（3）（1/2 ページ） グリーのサービス開発における継続的インテグレーションと、CIツールであるJenkinsの導入について、CI導入のモチベーション、進め方のポイントを中心に説明します。今回は、apkの作成までの自動化を手始めに、徐々に自動化の資産を積み上げていくことで開発ワークフローを改善していく過程を紹介します。 前回の「JenkinsでCIすればiOSアプリのビルドは、もう面倒くさくない」に続き、今回はAndroidアプリ開発とJenkinsについて紹介します。 Androidアプリのビルド Android開発の継続的インテグレーションの第一歩として、まずはAndroidアプリをJenkinsでビルドしてapkファイルを作成してみましょう。あらかじめJenkins、Andro
要件は 作業のログは永遠に残す必要がある いつ、誰が、どういった理由でインフラを変更したかわかるようにする ひとつ、落とすと インフラをコードで書けるようにする 開発、本番共にVMWareで構成された基盤なのでVMWareの仮想マシンが作れるコードを書く インフラコードをバージョン管理し、変更毎に構築できるかテストする コードで構築されたインフラでアプリケーションの全てのテストが通るか確認する（インフラの要件は設定ファイルがあるかどうかではなく、アプリケーションが動作するかどうか） テストは既に動作しているCIがあるので、それを使い回す ログの保持もJenkinsにしてもらおう やること Jenkinsから仮想マシン作成、OSのインストール Jenkinsのノードに作成された仮想マシンを追加 追加されたノードでOSインストール後の設定やミドルウェアのインストール 環境の整ったノードに対して
Jenkinsのプラグインでビルド・パイプラインを作ることができるので紹介。 ＃12月20日のワンクリックデプロイ勉強会の発表のネタバレっぽいのですが。 ビルド・パイプラインとはビルド・パイプラインとは、継続インテグレーションのプラクティスの１つで、テスト等を複数の単位に分割し、順番に流していくものである。一般的には継続的インテグレーションを利用していれば、SCMにソースコードをコミットした段階ですぐにユニットテストを走らせ、以降に、静的解析や結合テスト、受け入れテスト、ステージング環境へのデプロイ、本番環境へのデプロイという形で進んでいくことになり、その単位でパイプライン要素を分ける。当然パイプラインの途中で試験に不合格であれば、その後のプロセスには進めない。 これによって、例えばコミット時には即座にユニットテストレベルの結果を返して開発者のペースを阻害しないようにすることができる。（も
Goal Jenkins で達成出来る事は沢山ありますが、この記事では複雑な設定を伴わないで実現可能な、apk の自動生成、テストの自動実行までを対象とします。 またビルドツールも Ant, Maven, Gradle, Ivy 等がありますが、標準でもサポートされており、最小構成な Ant を選択しています。 ※ Jenkins でどこまで自動化したいかによりますが、様々なタスクを実行しようと思うと豊富な Plugin を持つ Maven が便利ではあるので、それはまた別途。 ant でビルド出来る様にする Jenkins で CI するには、まずはプロジェクトをコマンドでビルド出来る必要があります。 Eclipse で作成したプロジェクトでは、そのままではビルドする事が出来ない為、後から Android SDK に含まれるコマンドを利用して Ant 用の build.xml を生成しま
はじめに はじめまして。（株）ミクシィの加藤和良です。2008年度に入社し、2011年1月からはシステム本部 技術部に所属しています。技術部は、日記やコミュニティといった特定のサービスに紐づかない、mixi全体を裏から支える部署です。「支える」ための方法は、実際のサービスの一部として動作する共通基盤から、開発効率を上げるために社内で動作しているものまで、多岐にわたります。 mixiでは、ここ数年で自動テストの導入が急速に進みました。図1は、mixiのソースツリーにおけるコードと、そのテストコードの毎月1日のバイト数をグラフにしたものです。2008年の頭には少なかったテストが急速に増え、今年の5月にはコード量をも追い越しているのがわかります。 携帯電話向けmixiである「mixiモバイル」の開始が2004年、mixiニュースが2006年ですから、2008年当時のmixiも、それなりに大き
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド） 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。 サイト情報 （これAnalyticsを直接貼るのはどうやればいいんだろう？） 直近一ヶ
こんにちは。加藤和良です。 まずあの話を書いて、それを前提にあの話を書いて、みたいなキューが筆者の中にはあったのですが、正直キューの先端につまってる話はだんだん個人的な関心および記憶がうすれてきました! 昔のはなしですからね。 というわけで、最近のまとめをさらっと書いて、新しいネタをすぐ書ける状態にリセットしたいと思います。 Jenkins mixi ではバージョン管理システムとして Subversion を使っています。安定した、いつでもリリースできるバージョンを trunk に、開発中の機能は branches 以下に作業ブランチをつくり、レビューや QA などの後に trunk にマージする、という運用です。 Buildbot はこのうち trunk だけを追っていたのですが、徐々に「このブランチも Buildbot で追うようにして、結果をこの IRC チャンネルに書きこんでほしい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
