werckerの基礎知識 - Qiita
基礎概念 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 をつかったデプロイをwerckerで自動化する - Qiita
はじめに Serverless Frameworkを利用してAWS Lambdaの関数をpythonで開発しています。 機能実装するたびにデプロイするのが面倒だったので、CIサービスであるWerckerを使って自動化したときのメモとなります。 AWS LambdaのFunctionデプロイ 何も考えずにデプロイしようとすると、ローカル環境で開発したコード群をzipファイルにアーカイブしてAWSのコンソールからアップロードする感じになります。 デプロイ以外にもテスト実行など色々と面倒なので、多くの人がServerless Frameworkを利用していると思います。 Serverless Frameworkを利用したデプロイ Serverless Frameworkはサーバレス環境でのAPIやFunctionの開発をいいかんじにサポートしてくれるライブラリです。 デプロイも以下のようなコマン
Google App Engineへのデプロイをgithub -> werckerで自動化する（手動でもできるようにする） - Qiita
Google App Engineってサーバレスで大体のものは作れるので、とっても便利な感じです。 ただ、デプロイしようとすると、どこかのマシンなりサーバでdeployコマンドを叩かないといけません。 特定の開発者のマシンに依存すると、デプロイの回数が多くなると負担になりますし、マシンがクラッシュするとデプロイできなくなる……という難点が。 とはいえ、デプロイ用のサーバをわざわざ用意すると今度は24/365で費用がかかるというデメリットが。 という訳で、werckerを使ってみようと思います。 staging環境は指定のブランチにpushされる度に自動デプロイ、本番には任意のタイミングで手動でデプロイできるようにしてみようと思います。 ※使用したソース https://github.com/fumihiko-hidaka/gae-deploy-test 簡単な仕組みの図 デプロイ設定ファイ
TravisCIでPythonのテスト時、SyntaxErrorが発生する問題 - Qiita
概要 python3.6でTravisCIを使用して、テストを実行した時に謎のSyntaxErrorが発生した問題について説明します。 SyntaxErrorの発生 ローカルの環境でpython3.6のunittestを使用してテストコードを書いていました。 もちろんローカルでもテストを定期的に実行していました。 実行方法と実行結果は以下です。 python -Wall -m unittest discover -s aetam/tests ..... ---------------------------------------------------------------------- Ran 5 tests in 0.026s OK 何も問題はありません。 私の思惑通りです。 ある程度区切りがついたので、コードをGitHubにPUSH！！ そうです。何も問題はなく、テストが無事通る
Oracle WerckerでGithubにpushされたら自動でCIが動くようにした - Qiita
TL;DR Githubにgit pushすると自動CIがテストしてくれるようにしたら最高でつよいエンジニアの人たちが「自動CI/CDは当たり前」と言ってる意味を完璧に理解した。 Oracle + Wercker 現在は自動CDまでは行っていなくてgit push→CI(Wercker)→Slack通知という流れになっている。 Wercker導入以前は誰かが書いたコードの一部がテストを通ってなかったり、rubocopが怒るようなコードの書かれ方をしていてその状態でマージされてしまって他人のコードに影響がでるということが起こっていた。 pushする前に手元でテストしろ！とかrubocop動かせ！問題あれば自動フォーマットしろ！とかレビューできちんと問題のあるコードを指摘しろ！というのはある。 だがしかし、人間はだいたい自分にとって都合よく忘れたり、「これくらいならいいだろ」と思ってミスを起こ
Travis CI で "npm ci" コマンドを使う - Qiita
npm ci とは 皆さんご存知かもしれませんが、 npm@5.7 から npm ci コマンドが使えるようになりました。 ci | npm Documentation The npm Blog — Introducing npm ci for faster, more reliable... Release v5.7.0 · npm/npm npm ci コマンドを簡単に説明すると、こんな感じです。 ただし、上記のコマンドと違って npm ci コマンドは package-lock.json ファイルを更新しません。 （ npm install コマンドは package-lock.json ファイルを更新することがあります） package-lock.json ファイルに書かれてあるパッケージのみをインストールするので、テストやデプロイなどの再現性が要求される環境で非常に有用です。 ま
Wercker に Chrome をインストールする - Qiita
Rails アプリケーションのE2Eテストを書きました。 構成は Capybara + Selenium + Headless Chrome です。 このE2Eテストを Wercker で実行するために、 下記のスクリプトで Wercker に Chrome をインストールしました。 - script: name: install chrome headless code: | apt-get update -y wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | apt-key add - echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list apt-
CI機能作成録02 - Testソース起動、必要パッケージ等々 - Qiita
前回まで だいぶ間が空いてしまったが、TravisCIの導入、テストの起動確認(Fail)までを行った。 https://qiita.com/pkkanai/items/df9f8debdb81e9c6137b ※作業を進めていたリポジトリがTravisCIとの連携がどうしても取れなくなってハマった挙句、作成し直したことは内緒 今回やること 実際にテストソースを書いてみて、TravisCIでテストがパスするところまでやってみる。 使用ツール等 ・TravisCI ・GitHub Desktop ・Atom（エディタ） 本題 まず前回作成のリポジトリ直下のディレクトリ構成から少し変えてみる。 下記ディレクトリを作成。 ・./tests/ ・./src/ テストコードとディレクトリ構成 上記ディレクトリにそれぞれtestコードを。リポジトリ直下に設定ファイルを2つ配置。 テストコード作成 .t
Werckerで「Mysql2::Error: Authentication plugin 'caching_sha2_password' cannot be loaded」が発生した際の対処について - Qiita
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 ~(略
industrial_ci で roslaunch test する 2. Travis CI と Github の連携 - Qiita
はじめに 今回は，Travis CIとGithubの連携方法です． 目次 はじめに Travis CI と Github の連携 ← 今ココ industrial_ciの導入 CMakeLists.txtの記述方法 ローカルでのチェック 実際のパッケージでの動作例 前提条件 前提条件として下記のものがあります． Githubのアカウントを持っていること Travis CIのアカウントを持っていること リポジトリが公開リポジトリであること Travis CIのアカウントは，Githubのアカウントと連携可能です！ なので，持ってなくてもゼロから作る必要はありません． また，非公開リポジトリの場合はどうするかというと， ローカルでのみテストする Jenkinsサーバーを自分で建てる という方法があります． 今回は，そういった例外を除いた場合についてご紹介します． 連携の手順 1. Settin
読んでおきたい記事まとめ - Qiita
個人的に読み直したい記事などをまとめておく。随時追加していく予定 seleniunの開発背景 https://codezine.jp/article/detail/10225 werckerの仕組み https://deeeet.com/writing/2014/10/16/wercker/ rbenv + ruby-build はどうやって動いているのか http://takatoshiono.hatenablog.com/entry/2015/01/09/012040 railsコンソールでPostgreSQLの情報を確認する http://tamata78.hatenablog.com/entry/2015/09/24/224839 Register as a new user and use Qiita more conveniently You get articles that
Dockerをテスト駆動開発していくための最小限のTips - Qiita
アプリケーション開発では テスト駆動開発(Test Driven Development: TDD) はもう一般的になってきましたね。テストコードがないと継続的に開発ができなくて怖いですよね・・・ TDDの基本的な考え方は以下のような流れです。 アプリケーションがあるべき姿を満たすようにテストを書く テストを実行して 失敗（RED）になることを確認する アプリケーションを実装してテストを 成功（GREEN）にする リファクタリングを行う つまり RED → GREEN → リファクタリング のサイクルを繰り返すことがテスト駆動開発です。 テスト駆動開発を行う目的は多々あるかと思いますが、 「キレイな実装をし、メンテしやすいコードを維持しながら継続的に開発を行うため」 というのが主な目的かと私は考えています。 さて、今回話題にあげたいのがインフラをどのようにして、テスト駆動開発の流れに乗せて
werckerを使ってgit pushでファイルをs3へアップロードする - Qiita
はじめに とあるデータファイルを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へファイルがアップロードされます アップロ
Travis CIで自動テストして、結果をGitHubのトップページに表示する - Qiita
概要 こちらの記事の「Git Hub のトップページに、テストに合格した証のTravis CI バッチを貼り付けてる(任意)」を参考にしてやってみたよ、という記事。 当方の記事「Node.jsのnpmでパッケージを公開してみた手順の記録」で作った、npmライブラリのGitHubリポジトリに対して、自動テストのバッチを貼り付けてみた。 公式の「To Get started with Travis CI」に従ってやってみたら、設定ミスでテストしたというプチ罠の記載を含む。 全体手順は、以下の通り。 GitHubのアカウントでTravis CIにサインインする。 自動テスト（ビルド）したいリポジトリにチェックを付ける（設定をOnにする）。 リポジトリ側に、設定ファイル「 .travis.yml 」を作成してコミットする。 より詳しくは、以下の公式ドキュメントのGetting Startedを参照
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Travis-CIのビルドステータスを教えてくれるGoogleHomeをDialogflowとWebHookで作る - Qiita
GithubのPRにWerckerのBotが出なくなった件 - Qiita
Travis CI で rustup にかかる時間を短縮したかったら $HOME/.rustup をキャッシュしよう - Qiita
Firebase Hosting+Travis-CIでGitHubからデプロイを自動化 - Qiita
Java+GradleのアプリケーションをWerckerでビルドとテストする - Qiita
Java+Gradle+Wercker構成でCodecovによるカバレッジチェックする - Qiita