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

2015年4月頃からDockerベースになったCIツールのwercker v2向け設定メモです。 リポジトリ > CI > 通知 > デプロイ と連携して動作するのに各サービスで設定が必要になるので手順をまとめました。 CI環境を作ってテストコードを書いておくとコミットの度に自動的にテストを実行、結果が通知されるので、いつの間にか動かなくなっていた、という状況が避けやすくなります。 1. 自動ビルド〜Slackへの通知設定 1-1. werckerに登録/ログイン werckerのサイトでアカウントを登録してログインします https://app.wercker.com/ 1-2. werckerにアプリケーションを登録 Create > Application からアプリケーションを登録します。 GitHubかBitbucketのリポジトリを登録できます。 リポジトリを選んでそのまま進め
CI を中心としたワークフローやリリース(デプロイ)自動化システムを構築するには、現在対象としているコードベースの状態を把握する必要があります ブランチは、feature か master か プルリクエストをマージしたのか タグはついているのか Travis CI でそれらを把握するためには表題にある 3 つの環境変数の意味と組み合わせを理解しないと出来ないのですが、まとまった公式のドキュメントやネット上のレファレンスが見つからなかったので書きます http://aniszczyk.org/2012/04/05/travis-ci/ より Travis CI を使ったリリース自動化の例 例えば、最近試した iOS のプロジェクトでは、次のような、Travis CI を使った比較的複雑な、ワークフローの構築とリリース自動化を行いました なぜこうしているのかという意図などは、リンク先の RE
Metalsmithはやりたいことをプラグインで導入していくスタイルなので、若干のとっつきにくさはあるかもしれません。ただ、だいたいの仕組みとよく使うプラグインを把握してしまえばあとは自由にサイトを作ることができるようになってくるので、Node製でそういったものを求めているのであればMetalsmithが最良の選択になりそう。自分が使っているプラグインの可能性もあるけれども、ビルドは他のジェネレータと比較して、それほど早いといった感じはないなので記事数が膨大の場合には微妙なのかもしれない。 hbsnow/4uing.net 自分のサイトも今のところMetalsmithで作成しています。 インストール まずはMetalsmithをインストール。 CLIを使う場合にはグローバルにインストールするのが普通なんだろうけど、CLIは使わないので普通にインストールしていきます。 これだけではほとんど何
CircleCI 1.0ではDockerのバージョンが1.10.0まででしたがCircleCI 2.0では最新のDockerを使用することができるようになりました CircleCI 2.0にDockerをインストールする 流れとしては以下のようになります 作業用のDockerコンテナを選択する remote dockerをセットアップする docker clientをインストールする circle.ymlに書き起こすとこのようになります version: 2 jobs: build: working_directory: /go/src/github.com/ieee0824/circleci-demo docker: - image: golang:latest steps: - checkout - setup_remote_docker - run: name: install Do
Rails勉強中です。いつもお世話になっているRuby on Rails チュートリアルで、CI使ったこと無いので勉強のためにwercker設定してみました。 色々参考にさせて頂き、とりあえずテストが動いてHerokuにデプロイするところまではたどり着いたのでいったんメモします。 Ruby 2.2.0 Rails 4.2.4 PostgreSQL Bitbucket Heroku Deploy Target 今回Deploy先にHerokuを指定したかったけど (na) がついていて何故選択できないのかわからずハマってしまいました。 custom deploy でデプロイできる事は分かったので、以下の環境変数とwercker.ymlファイルを設定し、取り急ぎ動くところまでは確認できました・・・ 環境変数 wercker側で設定した環境変数(Deploy Targetの環境変数で追加しました
概要 S3で静的コンテンツをホスティングしている場合に、そのコンテンツの更新をCircleCIを使って自動化する方法についてまとめます。 Maven等で出力したレポートのHTMLをS3で公開、更新するようなケースを想定しています。 前提 S3バケットは作成済である 静的ウェブサイトホスティングが有効になっている 手順 IAMユーザの作成 CircleCI用のIAMユーザを作成して、Access Key IdとSecret Access Keyを控える 専用のユーザを作成することをCircleCIも推奨している IAMポリシーの作成 S3の特定バケットにsyncできるポリシーを作成する 作成したポリシーにユーザを紐付ける Policy Generatorなど活用する サンプル { "Version": "2012-10-17", "Statement": [ { "Sid": "StmtXX
概要 もう随分と前に TravisCI から CircleCI へ乗り換えたのですが、いかんせん、便利な CircleCI をもってしても Android のプロジェクトのビルド時間は長くなり続け、ついに 1 回のビルドに 20 分を費やすほどにまで成長してしまいました。いくつか無駄を省いたり、キャッシュをしてみたりと言った策を講じたものの、目立った改善が得られませんでした。そこで CircleCI を脱却してみることにしました。現在、CircleCI を脱却し Wercker を利用することで 1 回のビルドが 5 分ほどで終わるようになりました。この記事には、何がどのようにして短時間で済むようになったかを書き記してあります。 問題の根源 そもそも CircleCI で時間がかかっている部分はどこかというところから見ていきます。現在のプロジェクトで使用している分には、以下に上げる部分でか
ちょっと迷ったのでメモ。 CircleCIのバッヂってなんぞ ↑こんなの。 CircleCIのテストが通っているかどうかを確認できる素敵なもの。 これが表示されてるリポジトリってちょっとかっこ良く見えませんか? CircleCI以外にもバッヂは色々あるが、ここでは紹介しない。 早速バッヂを作ってみる パブリックリポジトリかプライベートリポジトリかでやることが異なる。 1. CircleCI のダッシュボードから、バッヂを表示したいリポジトリの設定を開く 2. PROJECT SETTINGS 内の Status Badges を開く 3. バッヂ作成 3.1. パブリックリポジトリの場合 Branch: ステータスを表示したいブランチを選択(通常はmaster) Embed Code: バッヂ表示用のコードの種類(github用ならMarkdown) 3.2. バッヂ作成:プライベートリポ
ここに書いてある内容はすでに古い可能性があります。2015/02/07 現在で beta ですが、travis 側でも Elixir プロジェクトのサポートが入っていて、それに従うだけで Elixir プロジェクトを CI できます。詳しくは以下を見てください。 やることは2つあります。 travis ci で対象プロジェクトを有効に設定 GitHub に.travis.ymlを push 今回は後者の設定ファイルの書き方を扱うので、1. については参照先だけ載せて簡単に。 travis ci で対象プロジェクトを有効に設定 Travis CI で対象となるプロジェクトを有効にしておきます。 http://mochizblog.heroku.com/21 こちらの記事などを参考にサインアップ、プロジェクトの設定をしてください。 .travis.yml の書き方 色々と Elixir のプロ
{ "src_folders" : ["test/e2e/specs"], "output_folder" : "test/reports/", "custom_commands_path" : "", "custom_assertions_path" : "", "page_objects_path" : "", "globals_path" : "node_modules/babel-register", "selenium" : { "start_process" : true, "server_path" : "node_modules/selenium-server-standalone-jar/jar/selenium-server-standalone-3.0.1.jar", "log_path" : "test/logs", "host" : "127.0.0.1", "p
備忘録も兼ねて書きます。 この方法でもgh-pagesにデプロイ可能ですが、今回は個人ではなく OrganizationでのGithub Pagesの利用なので[組織名].github.ioにデプロイをします。 1. 開発用リポジトリを作ります。 適当に開発用のhtmlやcssをjsをおいてコミットしてください。 2. 別リポジトリ[組織名]/[組織名].github.ioを作成 リポジトリにはあとでファイルを追加するので空にしておいてください。 今回はexample/example.github.ioを作ったとします。 3. Travis CIの設定 ルートリポジトリに.travis.ymlを設置してください。今回は以下のとおりです。 デプロイの実行はdeploy.shで行います。 マスターブランチかつプルリクじゃない場合はデプロイをするようにしています。
##werckerとは werckerは、ホストしたリポジトリのビルドとかデプロイを自動で行ってくれるサービスです。ちなみに、middlemanは、ruby製のサイトジェネレーターです。 ここでいう自動化というのは、ローカルのファイルをcommitし、pushすれば、build,deployされるという意味で使います。 ##middlemanの使い方 middlemanの使い方は、とても簡単です。publicへのuploadまでの手順は、まず、テンプレートをダウンロードしてきて、bundleし、build, gitで管理している場合は、pushまたは、deployを済ませれば良いだけです。 仕組みは簡単で、middleman buildコマンドが実行されると、buildフォルダができますので、それをWeb Serverの方に、Uploadすれば、サイトを公開する形になります。 ここで、ビル
Travis CI から GitHub Releases にアップロードする Go などのコンパイラ言語で書いたソフトウェアを配布する場所として、最近は GitHub Releases を使うことが多いと思います。単純に Git tag と紐付けてファイルをアップロードする場所ですが、手作業でやるのも面倒なので CI と連携させるのが便利です。 Travis CI には Deployment の機能があります。その名の通り、アプリケーションのテスト/ビルド後に、外部の指定した場所へ成果物をデプロイする機能です。デプロイするトリガーとして「特定のブランチ」「git tag がプッシュされた場合のみ」「Go 1.7 ビルドのみ」のような条件が指定できます。 Deployment は、標準で GitHub Releases のインテグレーションを備えています (GitHub Releases U
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く