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

必須なのはdist: trusty, sudo: false, cache: yarnで、それぞれ以下のような意味合いです。 dist: trusty, sudo: false: コンテナベースのUbuntu 14.04 (public beta) イメージを利用する設定です。 このイメージにはYarn(pkg)がプリインストールされているため、この設定によりユーザ自身によるインストール用設定が不要となります chache: yarn: パッケージのインストールを高速化するためのYarn(pkg)キャッシュを有効にする設定です なお、Yarn(pkg)の実行には、Node4以上を必要とするためテスト対象のNodeバージョンには4以上(.travis.ymlのnode_jsディレクティブ)を指定1します。 yarn installが実行される条件 yarn.lockファイルがプロジェクトディ
概要 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
Go でツール書くときはタスクランナーとして make を使っています。ビルドだけじゃなくて、テストや配布用パッケージ作成も一括して make でやっています。 今回は整理も兼ねて、自分が普段どういう Makefile を使っているのか解剖していきます。 なぜ make を使うのか ビルドフラグ覚えるのが面倒だから、make は (Windows を除く) 大半のプラットフォームに入っていて使いやすいからというのが理由です。script/build みたいにシェルスクリプトを複数用意するのでもまあ良いと思いますが…。大半の Go プロジェクトは Makefile 置いてありますね。 make を使った開発フロー 基本的には、リポジトリを git clone / go get -d した後に以下のコマンドを打てばアプリケーションをインストールできるようにしています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く