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

Wercker という Continuous Integration(CI、継続インテグレーション)を提供する SaaS があります。 なんとベータ版で無料!使わない理由がありません。 CI というとコードのビルドやテストを行うものを思い浮かべる方が多いかと思いますが、デプロイにも使えて、非常に便利です! ただ、GitHub にプッシュ→Wercker でビルド&テスト実行→テストが通ったらデプロイ、という流れを考えると、GitHub、Wercker、デプロイ先と3つのサーバを経由しており、お互いにどうやって認証しているのか非常にややこしくなります(少なくとも自分は最初混乱しました)。 GitHub → Wercker これは Wercker のウェブサイトから簡単に設定できるので、割愛します。 Wercker サーバ → デプロイ先サーバ 1. ssh-keygen で新しい暗号鍵を生成
料金体系 Pricing and Information - CircleCI The first container is free and each additional one is $50/mo. 1Container無料で1Container増設毎に$50/月。 Containerって何? じゃあContainerって何なのか。そのまま答えになりそうな記事があったので雑に和訳した。 Pricing and Information - CircleCI How do containers work? Every time you push to GitHub, we checkout your code and run your build inside of a container. If you don't have enough free containers availab
今年の頭にWantedlyのCIサーバはJenkinsからwerckerになりました。βテスト中ということもあってGitHubのprivateレポジトリに対しても無料で使えるのですが、僕らの規模だと十分実用的に使えて満足しています。 個人プロジェクトでカジュアルにCIしたい時などにもオススメ。 ちなみに、Herokuなどへのdeploymentも自動化できるのですが、そのあたりのContinuous Deploymentまわりの機能は使っていません。 基本的にはwercker.ymlをレポジトリ直下に作成するだけで設定できます。実際に使っているwercker.ymlが以下にあるので参照してください。 CircleCIだとレポジトリの内容から設定ファイルもある程度自動生成してくれたりして便利なのですが(例えば、RailsでRSpec使ってることを検出してそれ用の設定ファイルを自動生成してくれ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※この記事はTSG Advent Calendarの1日目の記事です。 こんにちは。知らない人は知らないhakatashiです。今年もAdvent Calendarギリギリ投稿となりました。申し訳ねぇ申し訳ねぇ。 よく知られている通り、怠惰はプログラマの三大美徳のうちの一つと言われています(ギリギリ投稿の言い訳ではない)。つい先日もあらゆる行動を自動化したというハッカーの実話に基づいたHacker Scriptsが話題を博しましたが、この手のオートメーションはあらゆるプログラマの魂の源泉であるはずです。OSSにおける自動化といえばTra
CircleCI 1.0では正常動作したGitタグ・ジョブ実行が、CircleCI 2.0ではうまく動きませんでした。どうにかしようと四苦八苦したログをここに残します。 結論 GitタグをpushしてもCircleCIジョブが起動しませんでした。なので、masterブランチにpushされたときに最後のGitタグを取得してデプロイ処理を実行するようにしました。 動作確認用にu6k/sample-circleci-2.0リポジトリを作成しましたので、こちらの.circleci/config.ymlをご覧ください。 Gitタグ・ジョブ実行の関連スレッド CircleCIコミュニティや公式ドキュメントの関連スレッドを挙げます。 Git tag deploys in 2.0 - CircleCI 2.0 / 2.0 Support - CircleCI Community Discussion この
TL;DR tagでも前のworkflowsが動くようにする必要がある。 1.0のとき deploymentに書くだけで動いたのにどうして。 document(2017-12-31時点) https://circleci.com/docs/2.0/workflows/#git-tag-job-execution CircleCI treats tag and branch filters differently when deciding whether a job should run. 1. For a branch push unaffected by any filters, CircleCI runs the job. 2. For a tag push unaffected by any filters, CircleCI skips the job. サポートフォーラムに書く
EC-CUBE3 では、PHPUnit + Travis CI を使用し、ユニットテストを自動化しています。 しかし、ここでテストされるのは、単体テストであり、この他、ブラウザを使用しての受け入れテストが必要になってきます。 また、 PHPバージョンを変更してのテストは、Build Matrix で簡単に設定できますが、データベースのバージョンや、ブラウザの種類を変更するのは難易度が高いです。 EC-CUBE3 は比較的こまめにリリースすることで、品質向上を図っていますので、リリースのたびに、多くの環境で受け入れテストをするのは、相応の労力が必要です。ブラウザからのテストといえど、単純なものは自動化してしまいたいですね。 ここで登場するのが Codeception です。 Codeception とは? PHP で書かれたテスティングフレームワークです。 受け入れテスト(Acceptanc
基本的には、 https://circleci.com/docs/ios-code-signing/ の通りです。 設定が完了したものは https://github.com/noboru-i/kyouen-ios にあります。 (ほとんどは https://github.com/noboru-i/kyouen-ios/pull/29 のPRで行いました) 事前準備 CircleCiでiOSのビルドをするためには、Pricing and Plan Information - CircleCIにあるように、最低でも$39/月の課金が必要です。 また、GitHubとの連携設定や、fastlaneの利用のためのGemfileなどが必要です。 .p12ファイルをアップロード 今回はTestFlightで配信するため、"iOS Distribution"の証明書を発行しておき、CircleCIにアッ
Middleman は便利ですが、Jekyll のようにコミットするだけで GitHub Pages にデプロイできないのが玉に瑕。そこで、Wercker を使って GitHub に push されたら、自動でビルドしてデプロイするようにします。 Wercker への登録とアプリの作成 まず Wercker にユーザ登録。GitHub アカウントで登録できます。 Apps > Add an application でアプリを追加。かなり簡単に追加できます。オープンソースプロジェクトなら、3. Add werckerbot はスキップして大丈夫です。 Deploy Target の作成 できた app の Settings > Deploy targets > Add deploy target でデプロイ対象を追加。Auto deploy はチェックして、ソースの方のブランチ名を指定します
box: wercker-labs/docker no-response-timeout: 10 build: steps: - script: name: rvm install code: | sudo apt-get update -y curl -sSL https://get.rvm.io | bash -s stable source $HOME/.rvm/scripts/rvm rvm install 2.0.0 --default echo "gem: --no-rdoc --no-ri" >> $HOME/.gemrc - rvm-use: version: 2.0.0 - bundle-install # - script: # name: docker pull # code: | # docker pull tianon/centos:6.4 # docker pu
Wercker 基礎 + 外部構成図 + 内部構成図 #wercker 概要 継続的デリバリプラットフォーム Wercker の基礎と外部構成図、内部構成図 Wercker とは? Wercker は頻繁にテストやデプロイを行う開発者のための継続的デリバリ( CD )プラットフォーム。 継続的デプロイを利用することで、エンジニアはソフトウェア開発のおけるリスク・浪費を減らす。 Wercker 外部構成図 外部とのやりとりに視点をおいた場合の Wercker の構成は以下のようになっています。 git リポジトリへの push をトリガーとして、 wercker を呼び出し、 Buildpipeline にて各種処理を実行し、 クラウドへのデプロイを行います。 ※最後に、 Wercker 内部に視点をおいた構成図を紹介します。 Wercker pipeline Wercker にはアプリケー
by @mixiappwchr アプリ開発において、重要なのだけれども面倒なものの一つとしてCI環境の整備があります。 サーバーサイドについては、すでにtravis CI,Circle CI,wreckerなどのクラウドのCIサービスを用いて継続的にインテクグレッてると思いますが、アプリに関しては各サービスがアプリのCIに対応してなかったりするため、未だに、ローカルにmac miniなどおいてJenkinsさんとお付き合いしてる人も多いでしょう。 しかし、やはりローカルのJenkinsを使う場合だと サーバーサイドのCIはクラウドで済ませてるのに、これだけローカルだとリモートからのメンテが面倒。 そもそもjenkins自体設定が結構面倒 などなど、結構メンテに時間を取られたりします。 しかし最近になってCircle CIのiOS対応が進み、いよいよアプリCIのクラウドでの実行が可能な時代に
@takehiro に教えて貰ったCircle CIを使ってみるともの凄く良くて、とてもお勧めなので記事を書きました! Circle CIって何? Travis CIと同機能でWebでのUIが若干違うサービスです。 CIとしての仕事はきちんと行えます。 Circle CIの使い方 https://circleci.com/ にアクセスします。 Githubアカウントでサインアップを行います。 画面に従って進むとプロジェクトをfollowする画面が表示されます。 CIしたいプロジェクトをfollow後、"Done Managing Repos"をクリックします。 ここでは"camelmasa/spree"を選択します。 するとfollowしたプロジェクト一覧のテスト結果の画面が表示される様になります。 これでCIが出来る環境が整いました! 後はgithubにpushする毎にCIが実行される様
Circle CIの設定 Circle CI 上で動かしたいので、以下の設定が必要になりました。 2.0対応 Dockerイメージは ruby:2.3-node-browsers にする 失敗時のスクリーンショットをArtifactsに保存 store_artifacts を設定 日本語文字化け問題を解決する 2.0対応 Circle CI を2.0対応しました。2.0にしないと新しいバージョンのChromeが動かせないため1、Chromeのヘッドレモードでのテストができないからです。 Circle CI 2.0対応のときにはドキュメントを読みつつCircle CI 2.0 移行時のキャッシュ設定メモ - Qiitaみたいなメモを残しながらやりました。 Dockerイメージ ruby:2.3-node-browsers を使いました。-browsers つけたものにするのは、e2eテストに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く