Help us understand the problem. What is going on with this article?
概要 ある開発中プロジェクトで、これまで JS のテストカバレッジを活用出来ていなかったため軽い気持ちでやっていきをしたら、 開発環境では設定した閾値を越えるのに CI 上ではパスしないためデプロイできないという状況が起こりました。 環境 開発マシン OS: maxOS 10.12.6 Node.js: 10.8.0 npm: 6.3.0 CI (Wercker) OS: Debian stretch-slim Node.js: 8.x npm: 6.x どちらも Jest のバージョンは 23.4.1 を利用しており、 設定も package.json に記述しているため共通のものを利用しています。 また、カバレッジに関する設定は閾値の設定しか行っていません。 Jest 実行時のコマンドは以下。
build: steps: # プロジェクトルートを GOPATH 配下に移動 - wercker/setup-go-workspace: package-dir: <SOME_PATH> # glide をインストールして glide install する - glide-install # ビルド - script: name: compile binary code: | go build # テスト - script: name: test code: | go test 上記でローカル/Web共にCIが通るようになった。 課題 Wercker で Go の CI を実行できるようになった。しかし、 dep への対応はできていない。 glide 自身が dep への移行を促しているので、 dep に対応したい。 wercker/step-glide-install を参考にして s
GitHubで利用できるCIのひとつ、Werckerの基礎知識についてまとめる 1.Werckerとは 2012年にオランダで誕生したCI-as-a-Service。リポジトリへのソースコミットをトリガーとしてアプリケーションのビルド、テスト、デプロイを自動化できるサービス。読み方は「ワーカー」。 github、bitbucketで利用することができる。 2.特徴 Werckerは、リポジトリのルートに「wercker.yml」を準備し、その中にテストの実行環境やデプロイコマンドをあらかじめ記載しておくことによりソースがコミットされたタイミングで自動的に記述された処理を行ってくれる。 Werckerでは、その実行環境を"box"、コマンド群を"step"として自作することができ、それを「Wercker Directory」に登録しておくことで様々なテストから実行環境やコマンド群を呼び出すこ
wercker導入手順① 前回はwerckerの登録とアプリケーションの作成まで行いましたので、今回はymlというwerckerの設 定ファイルの作成から配備までを行います。 ここまでで一旦最低限の導入は完了となります。 ymlって? YAMLという表現記法の拡張子です。YAMLとは何か?というと構造化したデータを記述するための表現記法で、Rubyやフレームワーク、ツールの設定ファイルなどでよく使います。 詳しくはこちらの記事で分かりやすくまとめられています。 WerckerではこのYAMLを使ってビルドやデプロイの手順を記載していきます。 wercker.ymlの設定 作成したアプリケーションを選択し、「runs」タブから使用言語を選択。 (ここではrubyを選択) ymlの内容をコピーし、ファイル名を"wercker.yml"として保存する。 box: ruby:2.4.2 servi
基礎概念 step pipeline(build deploy devなどのこと) workflow(pipelineをさらに組み合わせたもの) service(PostgresやElasticSearchなどを使いたい場合は、それらをserviceとして指定する) application user organization デフォルトではapplicationはpublicになっているので注意。 werckerの仕組み werckerはDockerベースである boxで指定したDockerコンテナ内で実行される boxにはDocker Hubに登録されているDockerイメージをなんでも指定できる PostgresやElasticSearchなどを使うにはserviceを使う serviceは別のDockerコンテナとして実行され、Docker Linkによってリンクされる あるコンテナ
はじめに Serverless Frameworkを利用してAWS Lambdaの関数をpythonで開発しています。 機能実装するたびにデプロイするのが面倒だったので、CIサービスであるWerckerを使って自動化したときのメモとなります。 AWS LambdaのFunctionデプロイ 何も考えずにデプロイしようとすると、ローカル環境で開発したコード群をzipファイルにアーカイブしてAWSのコンソールからアップロードする感じになります。 デプロイ以外にもテスト実行など色々と面倒なので、多くの人がServerless Frameworkを利用していると思います。 Serverless Frameworkを利用したデプロイ Serverless Frameworkはサーバレス環境でのAPIやFunctionの開発をいいかんじにサポートしてくれるライブラリです。 デプロイも以下のようなコマン
Google App Engineってサーバレスで大体のものは作れるので、とっても便利な感じです。 ただ、デプロイしようとすると、どこかのマシンなりサーバでdeployコマンドを叩かないといけません。 特定の開発者のマシンに依存すると、デプロイの回数が多くなると負担になりますし、マシンがクラッシュするとデプロイできなくなる……という難点が。 とはいえ、デプロイ用のサーバをわざわざ用意すると今度は24/365で費用がかかるというデメリットが。 という訳で、werckerを使ってみようと思います。 staging環境は指定のブランチにpushされる度に自動デプロイ、本番には任意のタイミングで手動でデプロイできるようにしてみようと思います。 ※使用したソース https://github.com/fumihiko-hidaka/gae-deploy-test 簡単な仕組みの図 デプロイ設定ファイ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR Githubにgit pushすると自動CIがテストしてくれるようにしたら最高でつよいエンジニアの人たちが「自動CI/CDは当たり前」と言ってる意味を完璧に理解した。 Oracle + Wercker 現在は自動CDまでは行っていなくてgit push→CI(Wercker)→Slack通知という流れになっている。 Wercker導入以前は誰かが書いたコードの一部がテストを通ってなかったり、rubocopが怒るようなコードの書かれ方をしていてその状態でマージされてしまって他人のコードに影響がでるということが起こっていた。 p
Werclerのプロセスが失敗 連休明けのとある日、いつものようにgit pushすると、CIに使っているWerckerからエラー通知が届いた。 内容を見てみるとspecにたどり着く以前の、テスト用DBを作成するステップでエラーになっていた。 エラーメッセージは「Mysql2::Error: Authentication plugin 'caching_sha2_password' cannot be loaded」。 Mysql2::Error: Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/lib/mysql/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory ~(略
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く