以下は本スライドに関連する記事になります。 AndroidのCI環境をCircleCIからWerckerに移行しました http://tech.vasily.jp/entry/migrate_android_ci_from_circleci_to_wercker CircleCIでbuil…
![AndroidのCI環境をCircleCIからWerckerにした話](https://cdn-ak-scissors.b.st-hatena.com/image/square/dab24c6015b30d3e53f84cbd17effe9de31fb985/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff8ba6c6ddd3148719ee0995777a546a5%2Fslide_0.jpg%3F6471158)
概要 もう随分と前に TravisCI から CircleCI へ乗り換えたのですが、いかんせん、便利な CircleCI をもってしても Android のプロジェクトのビルド時間は長くなり続け、ついに 1 回のビルドに 20 分を費やすほどにまで成長してしまいました。いくつか無駄を省いたり、キャッシュをしてみたりと言った策を講じたものの、目立った改善が得られませんでした。そこで CircleCI を脱却してみることにしました。現在、CircleCI を脱却し Wercker を利用することで 1 回のビルドが 5 分ほどで終わるようになりました。この記事には、何がどのようにして短時間で済むようになったかを書き記してあります。 問題の根源 そもそも CircleCI で時間がかかっている部分はどこかというところから見ていきます。現在のプロジェクトで使用している分には、以下に上げる部分でか
前置き hakobera.hatenablog.com この記事を公開した当時はまだオープンにできなかったのですが、実はこの記事は2月25日にリリースされたスタディサプリ(受験サプリ)を Quipper のプラットフォームに載せ替えるという移行プロジェクトを前提として内容も含んでいました。 【公式】スタディサプリ|苦手克服・定期テスト対策~大学受験まで 無事にリリースできたので、このプロジェクトで変わったことや導入したソフトウェア、ツールについていくつかピックアップして書いていきたいと思います。 目次 メンバーが増えた Infra as Code Deis AWS ECS + Docker + Locust による負荷テスト nginx (HTTP/2, ngx_mruby) 分析基盤 技術的課題 メンバーが増えた 前回の記事を書いた時はインフラ関連のエンジニア(Quipper では En
CircleCIの特徴は1環境であれば無料でCI環境が利用出来る点です。環境構築が完了すると、GitHubのcommit毎にCIコンテナが立ち上がり定義した自動テストがコンテナ上で実行されるようになります。本投稿では、Python3.5とFlaskで構築したWebサーバをCircleCI上で稼働させて、requestsを使ってコンテナ上のWebサーバにアクセスしてHTTP Statusコード200が返却されることを試験しています。 2時間で構築するCI環境の動作フロー Python3.5 + Flaskで構築されたWebサーバを試験する CircleCI上でPythonのWebフレームワークであるFlaskを利用したWebサーバを立ち上げて、HTTPのエンドポイントにアクセスしてHTTP Statusを確認する簡単な試験を行うのが本記事です。 jenkins職人問題へのCircleCIの考
はてなブログを複数人で運用しているとレビューどうしようってなる。 GithubだとPR作成して1行1行でコードがいじれるからめっちゃ便利! とはいえPR通った後は手動ではてなブログへ移す? CircleCIとは? https://circleci.com/ 知らない方は下記が参考になりそうです http://www.slideshare.net/mogproject/circleci-51253223 CircleCIはサーバー上で一通り遊べる環境が整っている Ruby, node.js, Python, PHP, Java, Scala, Clojure, Haskellと色んな言語をサポートしている 他にはsolr, elasticsearch, cassandra, neo4j databaseはmysqlとかmongodb、redisとかmemcachedだってサポートしてる 足り
サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ] (Software Design plus) 2016/02/26 に出版される「サーバ/インフラエンジニア養成読本 DevOps編」というムック本にて、特集「CircleCIによる継続的インテグレーション入門」を執筆しました。 CircleCIによる継続的インテグレーション入門 私が現在所属するKaizen Platform, Inc.でもCircleCIをヘビーユーズしており、サーバ/インフラ部分においても、 インフラCI 稼働中サーバへのプロビジョニング DNSレコードの管理 Terraformを用いたAWSリソースの管理 Packerを用いたAMI作成 稼働中サーバのセキュリティアップデート メトリクスグラフの取得&slackへの投稿 などにCircl
CircleCI で、とあるプロジェクトの CI 環境を作りました。このプロジェクトは、PHP 7 で開発しているのですが、まだ CircleCI 公式では PHP 7 がサポートされていません。 そこで、Docker を使って、PHP 7 + PhantomJS 環境を構築しました。 構成 PHPUnit と Codeception のテストを実行する環境を構築します。 コンテナの構成は、下記のようになります。 PHP 7 コンテナ PhantomJS コンテナ PostgreSQL コンテナ * 2 これらのコンテナは、docker-compose でまとめて構築、実行します。 PHP 7 コンテナ PHP 7 + Apache のコンテナです。Docker Hub オフィシャルの php:7.0-apache ベースにして、Laravel 5.1 実行に必要な拡張の追加や設定を行った
前置き AWS LambdaはEC2インスタンス無しでイベント駆動で必要な時に必要なだけコードを実行でき、課金も立ち上げているだけで料金がかかるEC2とは違い、完全なる使った分だけ課金という非常に強力で魅力的なサービスです。 しかし、このサービスはその軽量でシンプルなコンセプトとは裏腹に従来無かった独自の概念が多いためか、面倒なことや悩ましいことが多いと感じています。 だからこそ、もっと簡単かつ実用的に使いたいという想いからLamveryというツールを作っている訳なのですが、その中でも実用面で大きな課題となると感じていたデプロイの部分において、現時点で自分の中でのベストプラクティスと言って差し支えないフローを組むことができたので紹介したいと思います。 Lambda functionのdeployにおける3つの課題 ①デプロイパッケージの作成 Node.js npm installしてnod
この記事は CircleCI Advent Calendar 2015 - Qiita の 2 日目の記事です。ちなみに 1 日目は @stormcat24 さんによる”CircleCIでサクッとビルドチェーンを実現する”お話でした。 というわけで、2 日目は、SmartNews’s Journey into Microservices という LT をしてきました のスライドで少しだけ触れている、Docker コンテナを AWS CodeDeploy + CircleCI でデプロイする話について、簡単に説明しようと思います。 背景 僕が所属しているスマートニュースという会社では、Java でアプリケーションが書かれていることが多いため、JAR/WAR を持ってきて実行するようなことを CodeDeploy を使った Pull 型デプロイでやっています。一方で、一部のアプリケーションは依
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(
こんにちは!@riaf です。 今日は PHP BLT #1 ですね! (LTネタの仕込みもせずにこんな記事を書いていて良いのでしょうか) 弊社では、サービスの CI / デプロイ等に CircleCI を利用しています。 最近の PHP 開発では、Composer を使うことが多いと思うのですが、Symfony Components とかを使い始めると、依存するパッケージが多くなってしまって、CI 時の composer install に思いの外時間がかかってしまうこと、ありますよね。 特に、頻繁にテストが行われるようになると、Composer が GitHub の API リミットに引っかかってしまい、アーカイブではなくソースコードを clone してリミットを回避するので、より時間がかかるようになってしまいます。 「どうにかしたいですよねー」という声が上がってきたので、「よーし、い
井原(@ihara2525)です。 (引き続きめちゃ小ネタです) 「CircleCIでElasticsearchのログが吐かれていない問題を修正する」でタイトル通りCircleCIでElasticsearchのログが吐かれるようになったのですが、その対応だと/var/log/elasticsearchディレクトリの権限を変更してあげたりする必要がありました。 /var/log/elasticsearchにログを吐く設定がこのコミットで入っていて、同時にpath_logsというオプションで場所を指定できるようになっています。 /tmp以下には書き込めるだろうということで、以下のようにクラスタを立ち上げてあげると良さそうです。 Elasticsearch::Extensions::Test::Cluster.start(path_logs: '/tmp/log/elasticsearch')
現在、家族アルバム みてねというアプリのAutoLayout対応を進めていて、弊チームでは以下の3つのルールを対応必須とすることにしてみました。 全てのStoryboard/Xibでuse AutoLayoutのチェックを有効にする 全てのStoryboard/Xibでuse SizeClassesのチェックを有効にする AutoLayoutのmisplacedは必ず解消した状態でコミットする AutoLayoutはとにかく仕様が複雑で開発するのが大変なので、少しでも楽にしていくために最低限機械的にチェックできるところを自動化しました。 #!/bin/bash ! find . -name '*.xib' -o -name '*.storyboard' | xargs grep misplaced 2>&1 > /dev/null && \ ! find . -name '*.xib' -
モバイルアプリの知見共有会であるpotatotipsに初めてブログまとめ枠で参加してきました。 connpass.com potatotipsはビックリするくらい人気になっていて、一般枠の倍率が4〜5倍、発表枠でも抽選に漏れてしまうこともしばしば。ですが実はブログまとめ枠はなぜかいつも空きが出るくらいスカスカで、ちょろっと申し込んだら普通に通りました。 ブログまとめ枠は5人もいるみたいですし、資料はいつものGitHubリポジトリに上がると思うので、Androidの発表を聞いて自分が考えたことをメインにざっくりまとめたいと思います。 CIと実行時間 @tomoaki_imaiさんによる、メルカリでやっているCIに関する知見の共有でした。 Tips for better CI on Android from Tomoaki Imai www.slideshare.net 最近はCIツールが充実
Nightmare TL;DR Slack + Hubot + Nightmare + CircleCI を利用してSlackにNewRelicのメトリクスグラフやBIレポートを投げるようにした Slackなどチャットツールとのintegrationが無いツールでもグラフを投稿出来るようにした 会社のKPIやサービスの状態をSlack上からhubotを利用して誰でも簡単に確認が出来るようになった 仕組み Slack上でHubotを呼び出す(hubot-cronで自動で稼働する) HubotがCircleCIのAPIを叩いて、rebuid CircleCI上でNightmareを利用し、NewRelicやBIツールのスクリーンショットを取得し、s3にアップロード SlackのIncoming webhooksを利用してグラフを投稿する NewRelicにログインしてスクリーンショットを取るス
Serverspec の Docker Backend を使った Docker コンテナのテストを CircleCI 上で実行する際、多少手こずったので、その試行錯誤によってできた、サンプルプロジェクトを公開しました。 GitHub Repository quay.io Registry CircleCI Builds 前回の記事で紹介した事例は Rails を採用していたので、コンテナ側にも Ruby がインストールされており、コンテナ側にマウントするだけで Serverspec を実行できました。 docker run \ -e DATABASE_URL="${DATABASE_URL}" \ -e REDIS_URL="${REDIS_URL}" \ -v "$(pwd)/docker/serverspec"\:/mnt/serverspec \ --name "serverspec
エンジニアの内田 @spesnova です。 2015年8月5日に、@deeeet さんと一緒に Wantedly のオフィスにて Hashicorp Product Meetup と称して、 Hashicorp プロダクトに関する知見、悩み、展望 etc をフランクに共有する会を開きました。 参加者全員がゆるくざっくばらんに話せる場を作りたいと思って招待制のイベントにしました。 参加者の方は @deeeet さんと自分の知り合いの方から、Hashicorpプロダクトを既に利用していたり、導入予定の方々にお声をかけせて頂き、その方々がまた数名招待するという形にしました。 「行きたかった…」というツイートもチラホラありました、、参加できなかった方ごめんなさい。。 どんな内容だったのかをtogetterと以下に簡単にまとめておきます: http://togetter.com/li/856947
アプリ開発に自動化は必須か 「勢いよくアプリを開発したものの、デバイスごとにUIに不具合が……」 「テストを自動化したいけれど、やり方が分からない」 上記の方は、ぜひアプリ開発時のテスト自動化を図ってみてはいかがだろうか。 日経電子版×Sansanのアプリ開発勉強会、シリーズ第3弾。最終回のテーマは「アプリ開発時のテスト自動化」、「開発効率改善」。登壇者である辰濱健一氏、赤間夏樹氏、岸川克己氏の3名が経験した失敗、そして効率化への道を指南した。 【登壇者】 ・辰濱健一氏 (Sansan株式会社 エンジニア) 「アプリ開発作業の効率改善」 ・赤間夏樹氏(株式会社 日本経済新聞社 エンジニア)「CircleCI を導入してみた」 ・岸川克己氏 (アプリ開発テクニカルアドバイザー) 人数が少ないからこそ、作業の効率化が必要だった 最初のトークセッションはSansan株式会社エンジニアの辰濱健一氏
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く