はじめに とあるデータファイルを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へファイルがアップロードされます アップロ
ビルド結果の通知等を行ないたい場合は、werkecr stepからnotifyを含むstepを探してみるといいと思います。個人的にはwercker-step-http-notifyがオススメです:D。 おまけ: カスタムboxの作り方 werckerは非常に自由度が高いので、今回のように独自の処理系をインストールした環境をあらかじめ作っておくことができます。 これはCreating your own boxes with Bashにあるようにwerkecr-box.ymlを書くことで実現できます。 今回は、以下のようにUbuntu 12.04の上に依存パッケージ(libc6とgmp)を導入し、SML#のサイトで配布しているdebからSML#コンパイラのインストールを行なっています。 name: smlsharp-box version: 1.0.0 inherits: wercker/ub
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 で新しい暗号鍵を生成
今年の頭にWantedlyのCIサーバはJenkinsからwerckerになりました。βテスト中ということもあってGitHubのprivateレポジトリに対しても無料で使えるのですが、僕らの規模だと十分実用的に使えて満足しています。 個人プロジェクトでカジュアルにCIしたい時などにもオススメ。 ちなみに、Herokuなどへのdeploymentも自動化できるのですが、そのあたりのContinuous Deploymentまわりの機能は使っていません。 基本的にはwercker.ymlをレポジトリ直下に作成するだけで設定できます。実際に使っているwercker.ymlが以下にあるので参照してください。 CircleCIだとレポジトリの内容から設定ファイルもある程度自動生成してくれたりして便利なのですが(例えば、RailsでRSpec使ってることを検出してそれ用の設定ファイルを自動生成してくれ
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 にはアプリケー
Wercker Best Practice #wercker 概要 継続的デリバリプラットフォーム 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 Deployment #wercker 概要 継続的デリバリプラットフォーム Wercker の Deployment について。 Development Wercker は様々な PaaS 環境へのデプロイをサポートしている。 デプロイ先のことを Deploy Target と呼びます。 Paas 以外にも、 Fabric ・ Capistrano ・ プレーンな shell などもサポートしている。 Auto Deploying Wercker は Auto Deploying をサポートしている。 この設定を利用すると、デプロイがグリーンだった場合に、 特定のターゲットにデプロイを行うことができる。 これは、ブログなど低リスクのコンテンツに対して利用する際に便利です。 参照 Wercker | Deployment
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く