Travis CIでiOSアプリのリリース作業を自動化する - 24/7 twenty-four seven
この記事において利用している.travis.ymlとRakefileの全体はGistにて公開しています。 ↓ Rakefileの全体はこちら gist.github.com/kishikawakatsumi/8918124 ↓ .travis.ymlはこちら gist.github.com/kishikawakatsumi/8918365 概要 ユビレジではiOS アプリを申請する際に発生する作業の大部分をCIで自動化しています。 申請の作業としてユビレジでは下記のワークフローを決めています。 1. リリースブランチを作る 2. リリースするバージョンのバイナリをビルドする 3. 2と同等のアプリケーションを社内に配布して最終チェックをする 4. クラッシュレポートのサービスとしてCrittercismを利用しているので、そこにデバッグシンボル（dSYM）をアップロードする 5. 2のバイ
When was the build passing?
When was the build passing? その build passingはいつ? when was the build passing If you use GitHub, you often see Travis CI's badge on README. GitHubを使っていると、READMEにTravis CIのバッジが張ってあるのをよく見る。 Nice badge: build passing (Travis CI) build passing(Travis CI), ナイスバッジですね。 However, when the build passing, it is not clear until you see other date parts. ただ、いつのbuild passingなのかは、他のところを見ないとわからない。 authored on Jul 5
GitHub + Travis CI + Amazon S3 で git push で更新されるサイトをつくった - bouzuya.hatenablog.com
GitHub + Travis CI + Amazon S3 で git push で更新されるサイトをつくったので、その手順をメモ。 前提条件 GitHub のアカウントを持っている GitHub にリポジトリを持っている (例では bouzuya/bouzuya.net を使う) GitHub にリポジトリは Node.js のパッケージである (ルートにpackage.jsonがある) Travis CI のアカウントを持っている Travis CI の CLI をインストールしている (gem install travis) AWS のアカウントを持っている 概要 実現したい動きは次のとおり GitHub のリポジトリに git push origin master する Travis CI がリポジトリの更新を検知し Amazon S3 にデプロイ Amazon S3 にホストさ
手軽にCIを体験してみたい - MOL
昨年のFrontrend/06では、全くもってながら個人的な趣向のもと継続インテグレーション（CI:Continuous Integration）をテーマに開催した。もはや、フロントエンドとは！という感じだが、非常に良いイベントだったと思う。 基本的に昨今のフロントエンドは膨大なタスクに追われている、そのようなタスクを手動でちまちまやっていては手戻りやミスなど必ず発生するので自動化すべきである。フロントエンドの自動化はGruntなどがあるが、結局フロントだけで問題を解決しようとすると問題（限界）があったりするので、CIサーバーとか使ったほうがいいよね。てかフロントエンドの人も慣れておいたほうがいいよねって話。 しかし、フロントエンドの人がいちからJenkinsを立ち上げたりするのもさほど面倒でもないが多少の心理的障壁があるので、もっとカジュアルに利用したい。 Frontend/06の佐竹さ
Travis CIを使ったGitHubプロジェクトの継続的インテグレーション | 1000ch.net
継続的にテストをする 今更感が否めないのですが、簡単にまとめました。 Travis CIとはなんぞやという方はこちら。 継続的インテグレーションとはなんぞやという方はこちら。 例えばテストの自動化をして、リファクタリングのしやすい環境を作って、 コードの品質向上を継続的に行っていくサイクル。というイメージ。 今回はGitHubとTravis CIで自動化を測りますが、 Jenkinsでビルド環境を整えて、継続的にデプロイをしていくのもひとつです。 テスト周りの環境とか オレオレライブラリにCI環境整えました。一応。 mochaのBDDでテストケースを書いて、イベントのバインド周りのテストはsinon#spy()を。 testemでそのテストをPhantomJSで実行させるといった流れ。 PhantomJS testem mocha sinon mochaのサンプルは公式
How To Build A Ruby Gem With Bundler, Test-Driven Development, Travis CI And Coveralls, Oh My! | Smashing Coding
Ruby is a great language. It was designed to foster happiness and productivity in developers, all the while providing tools that are effective and yet focused on simplicity. One of the tools available to the Rubyist is the RubyGems package manager. It enables us both to include “gems” (i.e. packaged code) that we can reuse in our own applications and to package our own code as a gem to share with
Travis CI 入門：GitHub + Travis CI で継続的インテグレーション « をぶろぐ
1. Travis CI とはTravis CI はオープンソースコミュニティのためにホストされた CI（継続的インテグレーション）サービスです。 継続的インテグレーションってなんだ？ 継続的インテグレーション、CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。エクストリーム・プログラミング (XP) のプラクティスの一つで、狭義にはビルドやテスト、インスペクションなどを継続的に実行していくことを意味する。特に、近年の開発においては、継続的インテグレーションをサポートするソフトウェアを使用することがある。 引用: 継続的インテグレーション - Wikipedia Travis CI は GitHub と連携しており、CI したいリポジトリーを接続しておくと、Travis CI がコミットを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
