Jenkinsのビルドパイプラインでテストからデプロイまでを自動化 | HAWSクラウドサービス
開発プロジェクトでは、よく以下のようなライフサイクルが回ってる。 テストの実装 プログラムコードの実装 テストの実行 テストが通ったらコードをリポジトリにPush 定期的にCIサーバがリポジトリをチェックし変更があったらCIサーバ上でテスト実行 テストが通った状態のアプリケーションを検証環境へリリース 検証環境でのテストが通ったら、本番環境へリリース ※実際は５～７の間にDBのバックアップやマイグレーションとかいろんなタスクが結構ある。 このうち実際に人がやらないといけない作業は大体１～４ぐらいで、５～７については人が作業する必要はなく、自動化できる対象作業。同じ作業といっても手順が複雑であればミスをする可能性もあるし、人がする必要が無い作業を何度も人がするのはムダだ！ということで、今回はJenkinsを使って５～６の作業を自動化してみた。 必要なプラグイン 以下のJenkinsのプラグイ
テストを書く文化を育てる戦略と戦術
at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464Read less
JavaScriptのテストツール「testem」が素晴らしいぞ - Mach3.laBlog
この記事は賞味期限切れです。（更新から1年が経過しています） JavaScriptユニットテスト一年生の私が、Nettuts+ のチュートリアルで知ったテストツール 「testem」のお陰で大変捗ったので是非お勧めしたく、ここで紹介してみます。 testem ってなに testem via GitHub : airportyh/testem Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests. 要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ！というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応して
自動化や省力化の際の迷いについて | コーヒーサーバは香炉である
コーヒーサーバは香炉である スタイリッシュ僧帽筋プログラマごうだまりぽのブログですがデータが吹っ飛んでしまって仮復旧中。画像が入っていないところ、整形されていないところなどがあります。鮭とばは美味しいね。 検索 メインメニュー 何かを自動化あるいは省力化すべきかどうか。たとえばテストの自動化とか、最近だとCIとか。 導入にはそれなりに時間や費用がかかる。関与する人が多ければ調整も必要だ。新しいことを始めるというのは何かと労力と時間がかかる。そんなとき、つい疑問に思ってしまう。 「それで『元がとれる』だろうか?」 「結局手でやったほうが早いんじゃないの?」 手動で一回作業するのと自動でやるのを比べると、その所要時間の違いはほんの数秒、数十秒だったりする。たとえば1回の作業を10秒短縮するための作業に8時間かかったならば、2880回繰り返さないと「元を取る」ことができない。 塵も積もれば山
テストというのは、ソースコードの冗長化だと思う - きしだのHatena
テストというのは、基本的にはソースコードの冗長化だと思う。本来ならプロダクトコードだけ書けばよいところを、信頼性を高めるために複数の視点でのコードを追加する。 また、サーバーの冗長化で、２台構成を３台構成にするよりも、はるかに１台構成を２台にするのが難しいように、テストも、10本のテストを20本にするよりも、最初のテスト(プロダクトコードも含めると２本目のコード)を書くのが一番難しい。 テストがソースコードの冗長化であるなら、アクセスのないサイトでサーバーをクラスタリングするのが単なる金や設定時間の無駄であるように、長期的な信頼性の求められないプロダクトにテストを書くことも金の無駄だ。 アクセスが多いのにサーバー冗長化の金を払わない顧客に対してクラスタリング構成を構築する義理がないように、信頼性が求められるのにテストの金を払わず時間も確保しない顧客のためにテストを書いてやる必要もない。もち
hatahata's blog: Rails3.0 + Ruby1.9 + Rspec + Cucumber + Spork + Guard
May 21, 2011 Rails3.0 + Ruby1.9 + Rspec + Cucumber + Spork + Guard # 2011/5/26 change 'webrat' to 'capybara' ・make new project $ rails new hoge -T -J ・edit Gemfile source 'http://rubygems.org' gem 'rails', '>=3.0.7' gem 'rack' gem 'mysql' gem 'jquery-rails' group :development, :test do gem 'rspec-rails' gem 'rspec' gem 'spork', '>=0.9.0.rc7' gem 'cucumber' gem 'cucumber-rails' gem 'mechanize' g
僕のCode to Test Ratio歴
Ruby on Railsでの開発では、その規模の大小問わず、短期的・長期的問わず、最低限の品質を確保するためにテストコードの作成と自動化は「必ず」行うべきである、という考えを僕は持っている。つまり、テストコードのないRailsの成果物は、非常識きわまりなく、構造計算が一切行われていない建物と一緒。もしそんな開発プロジェクトがあれば、それは国会で取り上げられる程の騒ぎにならなければいけない事態であり、IT業界からご退場願わなければならない、と思っている。 さて、RoRでは、常に「自分がテストにどれくらい関わったのか」という指標を確認できるように、rake statsというタスクが標準で提供されている。これにより、実装コード行数とテストコード行数の割合がサクッと出てくる。もちろんカバレッジ率ではなく、総行数に関する指標であるので、あくまで参考値ではあるが、それを意識するのとしないのとでは大違
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IQ TEST