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のバイ
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
iOSアプリケーションのモンキーテストツール CrashMonkey について - Qiita
以前作ってGithubに公開していた CrashMonkey というツールについて紹介します。 Github:CrashMonkey CrashMonkey概要 iOSのアプリケーションをモンキーテスト（ランダムな操作をひたすら行う）するためのツールです。 動作イメージはこのデモ動画を御覧ください。 iPhone Simulatorの操作にはUIAutomationを使っていて、ベースとしてui-auto-monkeyを使わせて頂きました。 動作環境 以下の環境でのみ確認してあります。 Max OS X 10.8.4, 10.9.4 Xcode 4.6.3(Build version 4H1503), Xcode5.1.1 Ruby 1.8.7-p371 Rubyについては、1.9系, 2.0系でも動くと思います。 特徴 良い点 アプリのプロジェクト自体に変更を加えなくても実行することがで
アプリのクラッシュリポートを統計解析できるBugSenseの使い方
前回の「TestFlight＋JenkinsでiOSアプリのベータ版配信を自動化する」では、開発中のiOSアプリをTestFlightとJenkinsを使ってデバイスに配信する手順について解説しました。TestFlightを使うことによって、アプリのベータ版を手軽に、手早く配布できることがお分かりいただけたかと思います。 ベータ版配布を実施する意味はいろいろあると思いますが、ベータ版アプリを使ってもらうことによって、要望や意見などのフィードバックをもらいやすくするという点が一番かと思います。これだけでも大きなメリットですが、さらに効果を高めるためにはクラッシュリポートの分析が有効です。 ベータ版配信したアプリはデバッグを行えないため、クラッシュした場合に原因の特定が困難であるという問題があります。ツールやサービスなどを使ってクラッシュリポートを取得し、分析できるようにしておくことで、アプリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
