人気CIツール比較まとめ【2015年12月版】 - Qiita
概要 こんにちは。本日の担当の@hiro_kobaです。リブセンスでアクセスログ分析基盤の開発等をやっております。 本日は最近人気のある5個のCIツールを、色んな角度から比較してみようと思います。 背景 テスト環境でテストを実行し、通ったらステージングにデプロイ、その後動作が確認できたら本番デプロイ。 日々のオペレーションでよくある光景かと思いますが、手動での手順が多いためミスが発生しやすく、かつ手間も掛かるため、課題を感じておりました。 これらの継続的な運用フローを自動化してくれる仕組みとして、CIツールがあります。 CIツールは大きく分けて、以下3つに分類されるようです。参考 Everything（全方位型） Build, Test and Delivery（ビルド・テスト・デプロイ特化型） Specialization（その他特化型） 今回の問題には「Build, Test and
CIでの確認項目 - 弥生開発者ブログ
こんにちは、Misoca開発チームのmzpです。 GWは日光に遊びにいっていました。 MisocaではJenkinsを利用してCIによる自動テストを行なっています。最初はrspecを実行するだけのシンプルなものでしたが、都度設定を追加し、様々な項目をCIで確認するようになっていきました。 今日はそのCIで確認している項目について紹介したいと思います。 確認している項目 静的解析 コーディングスタイルのぶれや脆弱なコードを書かないようにするために、各種静的解析ツール(Rubocop、HAML-Lint、Brakeman)を導入し、警告がでないことを確認しています。 導入した直後は違反箇所の一覧を作成するのみで、ジョブの成否とは無関係でした。しかし、だんだんと違反箇所の修正をしなくなってしまったので、今は違反箇所がある場合はジョブが失敗する設定にしています。 rspec 全specの実行はrs
イマドキのIDE事情 第137回 Travis CIとBuildHive、オンラインCIサービスを活用しよう - たけぞう瀕死ブログ
IDE連載の第137回です。今回はオンラインCIサービスということでTravis CIとBuildHiveを紹介させていただきました。「IDEじゃないじゃん！」という突っ込みが入りそうですが、開発環境に関するトピックを幅広く取り上げさせていただくということでご容赦いただければと思います。 http://news.mynavi.jp/column/ide/137/index.html Travis CIとBuildHiveはどちらもGithubと連携したオンラインCIサービスという点ではよく似ていますが、細かい部分を比較すると、Travis CIは独自の設定ファイルをリポジトリにコミットしておく必要があるものの対応言語が多くクロスバージョンでのビルドが可能など柔軟性も高そう、という印象です。これに対してBuildHiveはプロジェクトの構造から自動的に最適なテンプレートを使用してジョブの設定
継続的インテグレーションを始めるための基礎知識
継続的インテグレーションを始めるための基礎知識：グリーはいかにしてJenkinsを導入したのか（1）（2/2 ページ） どのCI製品／サービスを利用するかの3つのポイント どの製品あるいはサービスを使うか最初は、次のような視点で考えると良いでしょう。 【1】導入が簡単か まだCIを実施したことがないようであれば、ツールを導入するだけのために多くの労力をかけるよりもまずは導入して、経験を積むべきです。多機能／高機能であるよりも、まずは導入が簡単であるかどうかを判断基準にすると良いでしょう。 CIツールのためのサーバを用意できないようであれば、クラウドサービスの利用も選択肢として考えられます。 【2】サポート体制について CIを開発に取り入れるためには、手厚いサポートが欠かせません。オープンソース製品であれば、コミュニティがどの程度活発に活動しているかを確認しておくと良いでしょう。 【3】連携
Jenkinsと完全にサヨナラして、CircleCIに移行した話 - tehepero note(・ω<)
2015-07-02 Jenkinsと完全にサヨナラして、CircleCIに移行した話 CI Jenkins CircleCI 長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって（それなりにスペック高くて、slaveもぶら下がってる）、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用
無料でbitbucketのリポジトリをCI - Qiita
ゴール bitbucketのレポジトリにpushしたら、jenkinsに通知されてビルドが実行される 使うもの CloudBees (javaのpaasサービス / 最初からjenkins入ってる) 手順 ステップ1. まずは手動でbuildするところまで設定 CloudBees側 CloudBeesアカウント取得 jenkins(すでにインストールされてる)を起動(10分位かかる) 新しくビルドジョブを作成 ソースコード管理のURLを記入 例) git@bitbucket.org:XXXXX/XXXX.git ビルド手順を設定(テストの実行とか) CloudBees Public Key※1を手元にコピーしておく BitBucket側 アカウント設定設定画面からssh key※1を登録 注)レポジトリの設定ページの”デプロイ鍵”に設定しても手動ビルドは通るが、 pushを検知してbuil
JenkinsのGit Pluginの設定の意味がやっとわかった - Qiita
JenkinsでGitを使う時にはGitPluginを使うと思いますが、この設定の細かな意味がわからずにいたのですが、いい加減本腰で調べてみました。 GitPluginの設定ではビルド対象のブランチを指定します。 ここでは複数のブランチを指定できるのですが、１つのジョブで複数のブランチを指定するとどれが対象になるのでしょうか？また、ある特定のブランチを明示的にビルドするにはどうすればいいでしょうか？ 動作を調べたところ、このブランチ設定は「ビルド対象ブランチ」というよりも「更新監視対象ブランチ」と言った方がよさそうです。 実際の動作は以下のようになっているようです。 ジョブが実行される Gitをfetchし、リモートブランチの状態を収集 以下の手順でビルド対象ブランチを収集する [Branches to build]の設定（対象ブランチ設定）が１つだけで、その定義(変数は展開済み)が明確な
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
イマドキのIDE事情(137) Travis CIとBuildHive、オンラインCIサービスを活用しよう
Jenkinsによる継続的インテグレーション ここ最近、継続的インテグレーション (CI)ツールであるJenkinsが大きな注目を集めている。継続的インテグレーションとは、ソフトウェアのビルドを定期的に実行することでコンパイルやテストが通らないといった問題を早期に発見するというものだ。CIは自動化されたビルドスクリプトさえ用意すれば開発言語を問わず導入することができ、既存の開発環境や開発プロセスにドラスティックな変化を必要とせずに導入できるため敷居も低い。 JenkinsはわかりやすいWebベースのインタフェースを備えており、手軽に導入できるという点が大きなメリットだが、ことオープンソースプロジェクトに関してはより手軽にCIを実現する選択肢が存在する。それがオンラインサービスとしてCIツールを提供しているTravis CIやBuildHiveだ。 Travis CIはオンラインCIサービス
「GitHubにpushしたら自動でビルド」を実現する「BuildHive」、米CloudBeesがリリース | OSDN Magazine
米CloudBeesは5月17日、GitHub向けの継続的インテグレーション（CI）プラットフォーム「BuildHive」を公開した。CIツール「Jenkins」をベースにしたオンラインサービスで、無償で利用できる。 BuildHiveは、GitHubレポジトリ向けに「Jenkins」ベースのCIビルド・テストジョブを容易に設定できるクラウドサービス。Jenkinsは「Hudson」フォークで、元々はSun MicrosystemsのプロジェクトだったHudsonがOracle買収後、商標問題などでもめたためにJenkinsに名称を変更した。Hudsonを立ち上げた川口耕介氏らがプロジェクトを率いており、川口氏が所属するCloudBeesの支援を受けている。 BuildHiveはCloudBeesが提供するクラウドベース開発サービスの1つで、GitHubにコードをpushするたびに自動でビ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MACへJenkinsをインストール(インストールの仕方編) - Qiita