werckerのinternal/docker-pushは予め用意したコンテナ内で様々な処理をして その処理結果をコンテナイメージとして固めて PUSHする stepである。 GCR(Google Container Registry)の他Docker Hubやquay.io、ECRにも対応している。 ※ 2017/4/10に見たところマニュアルが修正されていたので日本語での参考情報程度に... GCRの v1 API廃止の影響で、マニュアル通りだとPUSHができないので対応策を以下に示す。 公式のマニュアルが更新されるまでのつなぎで。 slackのwercker communityでは対応策が示されているけど流れるだろうし... 公式のマニュアル ただしこのマニュアル通りだと動作しない。 このままだとGCR v1 APIを使用してPUSHを行うようだが、 https://cloud.go
概要 API GatewayとLambdaを使ったAPI開発時のCI/CDについての記事です。 僕がnode.jsを普段から使用しているため、解説はnodeがベースになっています。 https://github.com/horike37/serverless-api-integration-test-sample ソースはすべてGitHubに上がってますのでそちらもご確認ください。 CIで実施する内容 以下の内容をCIとして行うことを考えます。 ESLintによる構文チェック Mocha, Chaiを使用したユニットテスト APIをAWSへデプロイしてテストを行うインテグレーションテスト CDで実施する内容 以下のようなルールでデプロイのサイクルを回します。 Gitのdevelopmentブランチへのpushをテスト環境へのデプロイと想定。 構文チェックとユニットテストを実施。 ビルドが通
背景、目的 Amazon S3はクラウドスレージとしてのみだけでなく、静的なWEBコンテンツの配信元としても利用できる。Amazon S3へファイルをアップロードするツールは数あるが、コンテンツのバージョン管理としてGithubを利用している場合、ファイル配置とバージョンの紐付けを行う必要性が生じうる。今回は、CIサービスのtravis-ciを利用してこれを実現する。 手順 AWSにデプロイ用アカウントの作成 S3にバケットの作成、権限の編集 travis.ymlの設定 デプロイ用アカウントの作成 travis-ciからのデプロイは、専用ユーザーを作成しそのユーザーアカウントを利用してtravis-ciがAWSのAPIを叩く。まずは、AWSコンソールのIAMからグループを作成する。アクセス許可を設定し、S3へファイルのアップロードができるようにする。本当は細かく設定するべきだろうけど、今回
ecrにdocker imageを上げるのを毎回手動でやるのは結構疲れます。ですのでtravis-ciを使って自動化しました。 .travis.ymlを作成する まず、このgistをそのままコピーして.travis.ymlを作成しました。 awsの環境変数を追加する ecrにdocker imageをpushするためには AWS_ACCESS_KEY_IDと AWS_SECRET_ACCESS_KEYが必要です。これをそのまま.travis.ymlに書くのはまずいので暗号化して.travis.ymlに追加します。そのために travisgemをインストールします。 travisgemをが環境変数の暗号化から.travis.ymlへの追加までうまくやってくれます。便利です。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? やりたいこと リポジトリへのコミットに伴う、CI(Continuous Integration)サービスによる自動ビルド起動を一時的にスキップしたい。 ※例えば、ドキュメントのみの更新等、プログラムに変更が無くテストやビルドが不要な場合 方法 コミットメッセージに含まれるキーワードでCI起動を抑制できる。 ※各CIサービスが個別にそうした機能を実装している 結論 GitHub Actions/Travis CI/Circle CI/AppVeyer/GitLab CI/CD PipelineのいずれかのCIサービスであれば、 [skip
WerckerはCIツールのひとつで、BitBucketやGitHubのリポジトリをターゲットにビルドや自動テスト/デプロイを実行することが出来るツールです。特にβ期間だからというのもあるのでしょうが、Github のプライベートリポジトリをターゲットにしても無料で利用できるというのは大きな魅力で人気があります。 このポストでは、Werckerをローカルで実行するためのツール、Wercker CLIについて解説したいと思います。 OverView WerckerはCIのホスティングサービスです。あらかじめWerckerのサイト上でGitHubのレポジトリを登録しておき、そのレポジトリ上にstep(一つ一つのビルド上の手続き)やpipeline(stepや後処理の集合)を定義したwercker.ymlというYAMLファイルに配備します。そしてその対象のリポジトリ上でGitHubのPull R
Go でツール書くときはタスクランナーとして make を使っています。ビルドだけじゃなくて、テストや配布用パッケージ作成も一括して make でやっています。 今回は整理も兼ねて、自分が普段どういう Makefile を使っているのか解剖していきます。 なぜ make を使うのか ビルドフラグ覚えるのが面倒だから、make は (Windows を除く) 大半のプラットフォームに入っていて使いやすいからというのが理由です。script/build みたいにシェルスクリプトを複数用意するのでもまあ良いと思いますが…。大半の Go プロジェクトは Makefile 置いてありますね。 make を使った開発フロー 基本的には、リポジトリを git clone / go get -d した後に以下のコマンドを打てばアプリケーションをインストールできるようにしています。
プライベートリポジトリの CI 無料でお馴染みの wercker が、先日ワークフロー機能 Wercker Workflows をリリースしました。 とりあえず、以下の公式デモ動画を観れば何ができるのかわかると思います。 ブログ記事 Introducing Wercker Workflows デモ動画 Wercker Workflows - YouTube Wercker Workflows とは いわゆるワークフロー機能というやつで、1つの CI プロセスを複数のパイプラインに分割して組み合わせる機能です。Jenkins とか、最近だと Concourse CI でお馴染みの機能です。 パイプラインは従来の build, deploy に相当するもので、1つの CI プロセス内におけるタスクの分割単位となります。従来は build, deploy の2つしか記述できなかったところ、tes
だいぶ遅れてしまいましたが、mixiグループアドベントカレンダー8日目の記事です。 はじめに ミクシィ・リサーチでは、デザイナーがいないのでフリーランスの方に外注しています。 外注する範囲としては、デザインからHTML/CSS/Javascriptに落とすところまで。 納品は、Git(BitBucket)でお願いしており、GitHubフローに近い運用をしています。 masterブランチとdesignブランチを用意し、デザイナーさんにdesignブランチへHTML等をpushしてもらい、その後一定の粒度でdesignブランチからmasterブランチへプルリクを出してもらいます。 プルリクが来たら社内でコードレビューを行い適宜修正をお願いするなどし、最終的にmasterブランチへマージします。 また、masterブランチ用のサイトとdesignブランチ用のサイトをHerokuで運用するようにし
@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が実行される様
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く