TravisCIとCircleCIでちょっとずつ違うビルド環境の考え方の違い
tl;dr TravisCIとCircleCIの根底にある違いの考え方を理解すると早い。 そして、違いを考慮しているproductを使うと便利。 e.g. checkstyle形式の結果をpull request review commentするsaddler CI result 考え方 CircleCI pushされたbranchをビルドする。 TravisCI pushされたbranchをビルドする。 pull requestのbranchを、仮にmasterにmergeしてみて、ビルドする。 仮にmasterにmergeしてみて?? TravisCIの二つ目のがわかりにくくて、混乱する。 やっていることは正しいんだけど、挙動が直感から外れるので、 TravisCIヘビーに使っているユーザーにもわりと意味不明挙動扱いされやすい(要出典) pull requestするとtravisのビル
Using Travis CI with Roswell
using-travis-ci-with-roswell.md Using Travis CI with Roswell Travis CI is the most prevalent cloud CI service. Though it has no Common Lisp support officially, by using Roswell, you can test your Common Lisp product with a few efforts. WARNING: This document is based on Roswell v0.0.3.42 (not released yet) or above. Enabling Travis CI To use Travis CI, you must sign up and enable testing for your
Google、DockerコンテナのビルドをREST APIなどで自動化できる「Container Builder」リリース。1日あたり120分のビルド時間まで無料
Google、DockerコンテナのビルドをREST APIなどで自動化できる「Container Builder」リリース。1日あたり120分のビルド時間まで無料 ソフトウェアの開発サイクルを迅速にまわすうえで、開発したコードをビルドし、テスト環境でテストをし、本番環境へ展開するといった操作を自動的に行う、いわゆるCI/CD（継続的インテグレーション／継続的デリバリ）の仕組みを構築することは欠かせないものになろうとしています。 こうしたCI/CD環境を構築するにあたって便利なのがDockerコンテナです。アプリケーションをDockerコンテナにパッケージすることで、軽量でポータブルなDockerコンテナの特長を活かして開発者が開発に利用しているノートPCからテスト環境、本番環境まで簡単に移動できるためです。 GoogleはこうしたDockerコンテナのビルドをRESTful APIを用い
人気CIツール比較まとめ【2015年12月版】 - Qiita
概要 こんにちは。本日の担当の@hiro_kobaです。リブセンスでアクセスログ分析基盤の開発等をやっております。 本日は最近人気のある5個のCIツールを、色んな角度から比較してみようと思います。 背景 テスト環境でテストを実行し、通ったらステージングにデプロイ、その後動作が確認できたら本番デプロイ。 日々のオペレーションでよくある光景かと思いますが、手動での手順が多いためミスが発生しやすく、かつ手間も掛かるため、課題を感じておりました。 これらの継続的な運用フローを自動化してくれる仕組みとして、CIツールがあります。 CIツールは大きく分けて、以下3つに分類されるようです。参考 Everything（全方位型） Build, Test and Delivery（ビルド・テスト・デプロイ特化型） Specialization（その他特化型） 今回の問題には「Build, Test and
バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
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】連携
GithubとbitBucketに対応しているCIツールwercker - Katlez’s blog
2016 - 02 - 05 GithubとbitBucketに対応しているCIツールwercker 思考の整理 開発 Docker この記事はWIPです BitbucketにCIを導入しようということになってwerckerを実装したのでまとめておきます。 色々とネットにある情報を見ながら実装したのですが、まずサービス自体が日本語対応していません。 また、Qiitaやブログにある情報も少なく、かつ2014年の頃の物が多くて2016年2月現在では仕様変更により変わっている部分も多く戸惑いました。 なのでこれからwerckerを使ってみようという方は情報の正確性に注意しながら実装してください。 なお、今回この記事を書く上で以下の記事を参考にさせていただきました。 これらの記事はとても参考になりました、ありがとうございます。 Werckerの仕組み，独自のboxとstepのつくりかた |
無料で使える CI サービス 8 個まとめ - 永遠に未完成
CI サービスをいくつか触ってみたのでまとめ。 今回の目的は、テストを実行すること。なので、ビルドやデプロイ辺りはちゃんとは見ていない。 ドキュメントで確認しただけの項目などもあったりするので、間違っていたらごめんなさい。教えてもらえると助かります。 ただ、これは記事を書いた時点での比較で、今後のサービスの変更に対応する予定はないです。 触ってみたサービス一覧 アルファベット順。 AppVeyor CircleCI Drone IO Magnum CI semaphore shippable Travis CI wercker codeship ってのもあったけど、無料プランは月100ビルドまでとかで常用には耐えないと感じたので中身見てない。 機能比較 機能比較は全て無料プランでのもの。有料だと対応している場合でもここでは x にしている。 比較項目は私の独断と偏見で適当に選出した。 項目
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
ひとりぼっちのサービス開発における技術選択の遷移と戦略 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? by @appwatcher 以前下記で書かせていただいた [goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話] (http://qiita.com/appwatcher/items/6c0280cda9c4c8b3c65f) ですが、上から下まですべてを担当して個々の技術をすべてやった経験自体も勉強になったのですが、 どうして、そのような技術選択をしたか？という点が自分でも振り返ってみて学ぶ点がありました。 それぞれ良し悪しがあったので何かしらの参考になればと思い、それ以後の技術変遷や取捨選択
JenkinsのGit Pluginの設定の意味がやっとわかった - Qiita
JenkinsでGitを使う時にはGitPluginを使うと思いますが、この設定の細かな意味がわからずにいたのですが、いい加減本腰で調べてみました。 GitPluginの設定ではビルド対象のブランチを指定します。 ここでは複数のブランチを指定できるのですが、１つのジョブで複数のブランチを指定するとどれが対象になるのでしょうか？また、ある特定のブランチを明示的にビルドするにはどうすればいいでしょうか？ 動作を調べたところ、このブランチ設定は「ビルド対象ブランチ」というよりも「更新監視対象ブランチ」と言った方がよさそうです。 実際の動作は以下のようになっているようです。 ジョブが実行される Gitをfetchし、リモートブランチの状態を収集 以下の手順でビルド対象ブランチを収集する [Branches to build]の設定（対象ブランチ設定）が１つだけで、その定義(変数は展開済み)が明確な
Go言語でのCI環境構築 - Preferred Networks Research & Development
PFNの柏原です。Go言語製のソフトウェアのCI(Continuous Integration, 継続的インテグレーション)環境の構築方法（導入方法）について解説します。想定としてはgithub上にホストしているOSSプロジェクトのソースツリーをCIの対象とします。OSSのpublicリポジトリなため、無料で使えるサービスを利用対象とします。 紹介する各CIサービスすべてでGo言語を扱えますが、まず最初にサービスを利用する上で各サービスについて結論から述べます。その後、各CI環境（OS、Goバージョン）、設定ファイルの例を説明します。 今回はTravis CI、CircleCI、Codeship、AppVeyor の4つのサービスを紹介します。 結論から 結論から書きますと、Linux, OS X, Windowsの各種OSプラットフォームで同時にCIを動かしたいなら、Travis CI(
iOSアプリ用のCI環境を作ろう - Qiita
12月からアクトインディにジョインしたkou_honです。 私、スマートフォンアプリエンジニアをやっております。 得意なのはAndroidアプリ開発なのですが頑張ってiOSアプリ開発もしています。 周りがRubyエンジニアの方たちばかり（そしてみんな優秀！）で毛色が違いますが頑張っていく所存ですのでよろしくお願いします 今回はiOSアプリ開発に先立って、CI環境を構築したので備忘録も兼ねて構築手順を書いていこうと思います。 ちょっと長い記事になっていますが、難しいことは書いていないので軽い気持ちで読み進めていってください 以下の構築手順でCI環境を構築すればGitHubのmasterブランチにソースがマージされたら、それをトリガーにBitriseがソースをクローン、ビルド、テスト、アーカイブを作ってDeployGateへデプロイ、slackへ結果を通知する環境が出来上がります。 #CIツー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub の公開リポジトリで Travis CI と Circle CI を使う - tnoda-clojure
Continuous Integration with Bitbucket Has Just Got Better - Semaphore
MACへJenkinsをインストール(インストールの仕方編) - Qiita
SLUG - November 2013