Amazon.co.jp： 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化: David Farley, Jez Humble, 和智 右桂, 高木 正弘: 本
Jenkinsでビルド・パイプラインを作る
Jenkinsのプラグインでビルド・パイプラインを作ることができるので紹介。 ＃12月20日のワンクリックデプロイ勉強会の発表のネタバレっぽいのですが。 ビルド・パイプラインとはビルド・パイプラインとは、継続インテグレーションのプラクティスの１つで、テスト等を複数の単位に分割し、順番に流していくものである。一般的には継続的インテグレーションを利用していれば、SCMにソースコードをコミットした段階ですぐにユニットテストを走らせ、以降に、静的解析や結合テスト、受け入れテスト、ステージング環境へのデプロイ、本番環境へのデプロイという形で進んでいくことになり、その単位でパイプライン要素を分ける。 当然パイプラインの途中で試験に不合格であれば、その後のプロセスには進めない。 これによって、例えばコミット時には即座にユニットテストレベルの結果を返して開発者のペースを阻害しないようにすることができる。（
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
