はじめに とあるデータファイルをs3へ自動でアップロードしたい要件がありました。 githubでファイルを管理してwerckerと連携してgit pushすると自動でs3へファイルアップロードするようにしたので、その備忘録です。 手順 Werckerに公開されているstep-s3syncを利用します。 利用方法はREADMEに記載されているとおりですが、以下のようになります。 deploy: steps: - s3sync: key-id: $AWS_KEY key-secret: $AWS_SECRET bucket-url: $BUCKET_URL source-dir: $SOURCE_DIR opts: --acl-private wercker.ymlに上記の設定を追加してworkflowsを設定してあげればgit pushで自動的にs3へファイルがアップロードされます アップロ
SML#で書かれたプロジェクトをWerkecrでCIできるようにする方法を書きます。 前提 対象のプロジェクトがGithub/Bitbucketにあること(プライベートレポジトリ可)。 make check等で単体テストが走るようになっていること。単体テストを書く際はSMLUnitがオオススメです。(というか他に選択肢がない) 設定方法 Werckerの設定 Werckerのアカウント取得やプロジェクトの作成等が必要ですが、そのあたりについてはGithubのプライベートリポジトリでも無料で使えるCI、Werckerを使ってrails newからHerokuのデプロイまでやってみるの「Werckerを設定する」が分かりやすいです。 wercker.ymlの作成 SML#インストール済のOS(werckerではboxと呼ばれる)はすでにmzp/smlsharp-boxとして用意してありあす。
box: wercker/ubuntu12.04-ruby2.0.0 services: - wercker/postgresql build: steps: - bundle-install - rails-database-yml: service: postgresql - script: name: echo ruby information code: | echo "ruby version $(ruby --version) running" echo "from location $(which ruby)" echo -p "gem list: $(gem list)" - script: name: Set up db code: bundle exec rake db:schema:load RAILS_ENV=test - script: name: rspec c
一応ここに全部書いてある Slack Notifications! slackのtoken取得 トークンの取得はIncoming WebHooksから行う https://各ドメイン.slack.com/services/new/incoming-webhookから nortification送りたいチャンネルを選択し Add Incoming WebHooksをクリック トークンが作成されるのでコピー サイドバーのTOKENと書いてある箇所にtokenが表示されてるのでコピー werckerのtoken設定 ApplicationのPipelineにtokenをペーストする ENVIRONMENT VARIABLEに適当な名前を付ける ENVIRONMENT VARIABLEで付けた名前はwercker.yml内で変数として使用できる textのvalueにコピーしたtokenをペースト
wercker の Coq box をけっこう前に作っていたのでその紹介です。 wercker は Travis CI のような CI as a Service と呼ばれる類の Web サービスです。基本無料です。 wercker では任意のアプリケーションをインストールした環境 (box といいます) を自分で作ることができて、その環境を使って CI をすることができます。 使い方 GitHub または Bitbucket にリポジトリ (Private でも可) を作り、wercker にそのリポジトリを登録します。 Make というファイルを作り、下のように Coq ファイルの名前を書いていきます。 ファイル名は Make でなくてもいいのですが、Coq演習第7回 に「Makeという名前にすることが多い」と書いているとおり ssreflect やその他いろいろなライブラリで Make
はじめに つい先日まで、EngineYard に Rails でアプリを構築して、自動テストは wercker でおこなっていたものの、デプロイは EngineYard のダッシュボード画面より手動でおこなっていました。 そろそろデプロイも自動化したいと思いましたが、wercker ではデフォルトでは EngineYardへのデプロイに対応していないません。どうも、Codeship というサービスが EngineYard へのデプロイに対応しているということで切り替えました。 しかしフリーでの利用はビルドが100回までという制限があり、実際運用してみると1週間ももたないということがわかり、Codeship の利用をあきらめました(コミットコメントに [skip ci] という文字列を含めると自動ビルドをスキップするという機能はあるのですが、100回という上限を気にしながら開発するのは精神衛
Wercker という Continuous Integration(CI、継続インテグレーション)を提供する SaaS があります。 なんとベータ版で無料!使わない理由がありません。 CI というとコードのビルドやテストを行うものを思い浮かべる方が多いかと思いますが、デプロイにも使えて、非常に便利です! ただ、GitHub にプッシュ→Wercker でビルド&テスト実行→テストが通ったらデプロイ、という流れを考えると、GitHub、Wercker、デプロイ先と3つのサーバを経由しており、お互いにどうやって認証しているのか非常にややこしくなります(少なくとも自分は最初混乱しました)。 GitHub → Wercker これは Wercker のウェブサイトから簡単に設定できるので、割愛します。 Wercker サーバ → デプロイ先サーバ 1. ssh-keygen で新しい暗号鍵を生成
Rails, Ruby 2.1.0, PostgreSQL, RSpec, Cucumber, PhaontomJS, HipChatの組み合わせでwerckerを使って気軽にCIするRubyRailsRSpecwerckerPhaontomJS 今年の頭にWantedlyのCIサーバはJenkinsからwerckerになりました。βテスト中ということもあってGitHubのprivateレポジトリに対しても無料で使えるのですが、僕らの規模だと十分実用的に使えて満足しています。 個人プロジェクトでカジュアルにCIしたい時などにもオススメ。 ちなみに、Herokuなどへのdeploymentも自動化できるのですが、そのあたりのContinuous Deploymentまわりの機能は使っていません。 基本的にはwercker.ymlをレポジトリ直下に作成するだけで設定できます。実際に使っているw
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 はチェックして、ソースの方のブランチ名を指定します
タイムアウトをデフォルトの5分から10分に延ばす 5分の場合、bundle installでこける 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 # c
概要 継続的デリバリプラットフォーム Wercker の基礎と外部構成図、内部構成図 Wercker とは? Wercker は頻繁にテストやデプロイを行う開発者のための継続的デリバリ( CD )プラットフォーム。 継続的デプロイを利用することで、エンジニアはソフトウェア開発のおけるリスク・浪費を減らす。 Wercker 外部構成図 外部とのやりとりに視点をおいた場合の Wercker の構成は以下のようになっています。 git リポジトリへの push をトリガーとして、 wercker を呼び出し、 Buildpipeline にて各種処理を実行し、 クラウドへのデプロイを行います。 ※最後に、 Wercker 内部に視点をおいた構成図を紹介します。 Wercker pipeline Wercker にはアプリケーションを配布するためのステップとフェーズのセットからなる パイプラインと
概要 Wercker command line interface として提供されている Python 製の wercker-cli を利用して、 CLI 経由で Wercker を操作します インストール pip のインストール(Ubuntu) $ sudo apt-get install python-dev $ sudo apt-get install python-setuptools $ sudo apt-get install python-pip $ pip --version pip 1.0 from /usr/lib/python2.7/dist-packages (python 2.7)
capistrano自体はcapistrano-ext使えばproductionとかstagingとか複数環境へのデプロイができるようになるけど、それをwercker使って複数環境に自動デプロイできるようにした。 こちらを事前に見ておくと良いかもです。 Rails+postgresql+capistrano環境のwercker設定 wercker.ymlファイル $WERCKER_DEPLOYTARGET_NAME という環境変数がdeploy先の名前として使える(後述の管理画面から指定するやつ)ので下記のようにymlファイルを作成する。 deploy: steps: - bundle-install - script: name: make .ssh directory code: mkdir -p "$HOME/.ssh" - create-file: name: write ssh
概要 Wercker + Bitbucket で Ruby のプロジェクトの CI を疎通させます 前提 Bitbucket は登録済み 事前に ci_sample というリポジトリを作成。簡単な実装とテストを用意しておく 適当な Ruby のプログラムを実装します 適当な Ruby のプログラムのテストコード( rspec )を実装します Gemfile を用意しておきます( rspec のみ指定) 手順 Wercker にユーザー登録 Apps + Add を選択 Choose a Git Provider Bitbucket を選択します Select a repository ci_sample を選択 Configure access Add the deploy key to the selected repository for me を選択します Bitbucket のデプ
概要 継続的デリバリプラットフォーム Wercker の Best Practice について。 Development Pull Request の ビルド結果を常に確認できる。 Deployment 一般的なデプロイは、 Staging と Production の二つの異なる 環境に行うことが多いです。 Production:本番環境 Staging:動作確認や問題の調査のために利用する本番に近い環境 Wercker でこの二つを実現するには Deploy Target を二つ作成する。 Staging への Build / Deploy が成功したら、 次に Production への Build / Deploy を行う。 Wercker 公式サイトの記事中の誤り(2014/11/17 時点) 説明中のリンクが死んでいるので後でプルリクエストを送る。 Wercker Best P
概要 継続的デリバリプラットフォーム Wercker の Deployment について。 Development Wercker は様々な PaaS 環境へのデプロイをサポートしている。 デプロイ先のことを Deploy Target と呼びます。 Paas 以外にも、 Fabric ・ Capistrano ・ プレーンな shell などもサポートしている。 Auto Deploying Wercker は Auto Deploying をサポートしている。 この設定を利用すると、デプロイがグリーンだった場合に、 特定のターゲットにデプロイを行うことができる。 これは、ブログなど低リスクのコンテンツに対して利用する際に便利です。 参照 Wercker | Deployment Register as a new user and use Qiita more conveniently
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く