Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この記事はWHITEPLUS Advent Calendar 2016 5日目になります。 株式会社ホワイトプラス、エンジニアの @akaimo です。 ホワイトプラスでは主にリネットのiOSアプリを担当しています。 iOSアプリのリリースや配布は手間がかかる iOSアプリをリリースしたり、開発版を配布しようと思うと、各開発者のMacに証明書をインストールしなければいけません。 しかし、Appleの証明書は複雑なため、なかなかスムーズにいきません。 また、アップロードできる人を絞ってしまうと、負荷の集中、不在時にどうするかなどの問題も発生します。 そこでホワイトプラスでは、Travis CIを利用してリリース・配布のフローを自動化しています。 CI環境を作ってしまえば、つい忘れていつの間にかテストが通らなくなっている、なんてことも防げ品質を高く保つこともできます。 利用するサービス Git
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは皆さん CIっていい響きですよね! 継続的インテグレーション、なんて日本語に訳すとなんのことだかわからないところもおしゃれです。 現在ポピュラーなCIサービスといえば、github連携のTravis CIじゃないかと思います。 ここは自分もおしゃれ開発の仲間入りしたい!とばかりに、Travis CIを使ってみたのですが、昔普通にphp環境で組んだことがあったので、今回はdockerを使ってしまおうと思い至ったのです。 ...まあ、オシャレで優雅に見える開発も、水面下で泥臭い検証実験を繰り返しているものです。 そんなわけで、Tr
前置き Wercker は Docker コンテナの中で CI をするサービスで、とりあえずビルドに必要な環境が整った Docker イメージがあれば、あとは Wercker が勝手にイメージを引っ張ってきてコンテナを立ち上げて指示通りビルドをしてくれるため、公式ドキュメントにはない Android アプリのビルドも可能です。 ビルドに必要な環境はすべて Docker イメージにまとめて放り込んでしまえるので、SDK の更新があったときに CI サービス側の対応を待たなくとも、自分でイメージを作り直すだけで環境を最新に保つことができる点が魅力ですが、裏を返せば自分で環境をメンテナンスしなくてはならないという面倒臭さがあります。 とは言え、CI サービス側が環境を用意してくれる場合でも、自分で環境をメンテナンスする場合でも、環境が新しくなってもビルドが壊れないことの確認は最低限する必要がある
Dockerコンテナを動かす時のメモリ制限 Dockerにはコンテナが使えるメモリの上限を設定するオプションがあります。 ただし、Werckerがコンテナで使用可能なメモリの制限をしていることはないようです。 @KeithYokoma currently, there is no limit for internal memory. If you're asking about storage, I'll need to get back to you! — wercker (@wercker) 2016年4月14日 とはいえ際限なく無限にメモリが使えるかといえばそんなことはないはずなので、物理的にどの程度まで余裕があるのか見たくなりました。 cat /proc/meminfo MemTotal: 65965708 kB MemFree: 19718212 kB MemAvailable:
この記事はWHITEPLUS Advent Calendar 2016 23日目になります。 株式会社ホワイトプラス、エンジニアの @akaimo です。 ホワイトプラスでは主にリネットのiOSアプリを担当しています。 はじめに WHITEPLUS Advent Calendarの中で以下の記事のように、iOS開発用のTravis CIを構築してきました。 Travis CIでつくるiOSのCI環境(準備編) Travis CIでつくるiOSのCI環境(テスト・アップロード編) 今回は最後の仕上げとして、運用する上でのコツを書いていきたいと思います。 実行時間の短縮 Travis CIの環境を構築したら、一番始めに課題となって立ちふさがるのは、実行時間の問題だと思います。 時間がかかるポイントとしては、 環境構築(ビルドまでの準備) ビルド アーカイブ アップロード があります。 アップロ
プロジェクトが落ち着いてそろそろCI/CDを導入したいねっていう状況でした。 CircleCIを別案件で使ってた人が近くに居るけどBitbucketではCircleCIをサポートしていないようですので、別のCIを検討する必要がありました。 そこで色々検討した結果Werckerを使ってみることにしました。(無料だし) しかし、WerckerはPHPをサポートしているけど、Quickstarts に書いてある事項はSymfony向きではないため混乱しました。 また wercker.yml に変更を加えていないのにBuildがfailedになることもありました。(僕は「werckerの機嫌が悪い」って呼んでる) 更にWerckerとWercker2の記述が有りググったときに更に混乱を招きました。 導入方法 前提/状況/目的 前提/状況 Bitbucketでバージョン管理してる(状態はプライベート
必須なのはdist: trusty, sudo: false, cache: yarnで、それぞれ以下のような意味合いです。 dist: trusty, sudo: false: コンテナベースのUbuntu 14.04 (public beta) イメージを利用する設定です。 このイメージにはYarn(pkg)がプリインストールされているため、この設定によりユーザ自身によるインストール用設定が不要となります chache: yarn: パッケージのインストールを高速化するためのYarn(pkg)キャッシュを有効にする設定です なお、Yarn(pkg)の実行には、Node4以上を必要とするためテスト対象のNodeバージョンには4以上(.travis.ymlのnode_jsディレクティブ)を指定1します。 yarn installが実行される条件 yarn.lockファイルがプロジェクトディ
はじめに 先日、 Terraform で Google Cloud DNS を管理して GitHub 経由で Wercker から反映する環境を構築し、その便利さに感動しました。 これには、大きく2つの恩恵があります。 Terraform と Git による DNS レコードのバージョン管理 GitHub と Wercker による自動反映 チーム開発などで複数人がレコードを管理する事が容易になる (Pull Request を出してもらってレビュー後に master へ merge するだけ) 割と嵌ったので、手順を纏めておきます。 尚、 GCP のアカウントは発行済で、プロジェクトも作成済みとします。 https://console.cloud.google.com/ 余談 筆者はこれまで Gehirn DNS を利用していました。このサービスは、自前で Git などを使うことなく D
プログラムの自動デプロイにCIがよく使われますが、単純に静的サイトをbitbucketで管理して、それをs3に反映するだけというカジュアルな使い方を試してみたかったのでメモ。 1. s3の設定をする 簡単にやるのであればManagement Consoleからパッとやればいいでしょう。 悩むところはそんなにない(はず) ansibleでやった際に引っかかったのが以下点なのでご参考に。 http://qiita.com/celeron1ghz/items/cdaa79d7e53524a97712 2. bitbucketでrepositoryを作る 「リポジトリの作成」より作成。 bitbacket側ではrepoを作るのみでOK。 3. werckerの設定 ここが微妙に引っかかった。 werckerにbitbucketのrepositoryを追加 上部メニューにある Create -> A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く