なぜリリース頻度を上げるのか
サービスのリリースで書いたようにネットのサービスを提供している企業は新バージョンのリリースの頻度を上げるよう常に努力しています。 リリースの頻度を上げる理由は、サービス開発の方向の軌道修正を細かく行いたいからです。少しずつサービスを改良し、その改良がユーザーにどのように受け入れられたかという反応を元に将来の開発を行っていきます。このフィードバックサイクルを短くすることによりこまめな軌道修正が可能になります。 リリース頻度が低く、リリースサイクルが長いと、その期間に加えられた変更の数が多くなり それぞれのリリースでの変更量が大きくなります。変更が多い分、リリース後の不具合発生の可能性が高くなります。また、リリース後の障害発生時の問題の切り分けも難しくなります。小さなリリースを頻繁に行うことにより、一歩一歩問題がないことを確認して次の一歩を踏み出すように、よりリスクの少ないリリースが可能になり
Ciしてるかい？
The document discusses continuous integration and delivery practices for software development. It recommends committing code changes to version control daily, configuring an automated build and test process every time code is committed, and deploying successfully built code to testing or production environments. This allows developers to identify issues early, prevent broken code from being deploy
継続開発のススメ [Python 温泉編] - Twisted Mind
とりあえず書き出してみました、これから色々修正します。 こうしたら良いと思う、こうしたら良かったの両方がごちゃごちゃっとなってますが、あくまで考え方なので銀の弾丸ではありません。 #bucho Python 温泉で @torufurukawa と色々話しをしました、いい機会なのでまとめてみます。 自分が色々やっている中で、こうした方がいいと思いますという内容がほとんどです。 @torufurukawa がエントリあげてました、実践的な話しなのでオススメです。 Even More Addicted to Indentation: Python 温泉で開発プロセスの教えを乞う 銀の弾丸はない 開発手法にベストプラクティスはありません。環境、仕事内容、人によってそれぞれでしょう。 そのため、今回書かれていることが銀の弾丸になる事はありません。 開発手法は固定するモノではなく、常々変化するモノです
![継続開発のススメ [Python 温泉編] - Twisted Mind](https://cdn-ak-scissors.b.st-hatena.com/image/square/79422068138e0125099cf8f4274a0dab3b9bcb86/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704346814673863427%2F12704591929890553532%2F1348335157)
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
Buildbot で継続的インテグレーション - mixi engineer blog
こんにちは。パートナーサービス部の加藤和良です。 前回、mixi における開発者テスト について説明しました。だいぶ間があいてしまいましたが、今回は、そのテストを定期的に実行する 継続的インテグレーション の仕組みを紹介したいと思います。 テストが遅い 実は、mixi のテストは「遅い」という大きな問題を抱えています。 Micheal Feathers は『レガシーコード改善ガイド』のなかで、単体テストが高速に実行できることの重要性を解き「単体テスト」を厳しく定義します。 次に当てはまるものは単体テストではない。 データベースとやり取りする ネットワークを介した通信をする ファイルシステムにアクセスする 実行するために特別な環境設定を必要とする (環境設定ファイルの編集など) 上記に該当するテストが悪いというわけではない。多くの場合において、そのようなテストを書く価値はあり、しばしばテスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安全な継続的デプロイメントのための知覚的テスト
Blogger
