git-pr-releaseのすすめ - ninjinkun's diary
Github (含むEnterprise) で開発をしているなら、Github Kaigiでも紹介されていた git-pr-release が便利です。自分の会社ではアプリのリリース前にQAを実施しているのですが、QAを始める前にどの機能がリリースされるのかをリストアップし、それをGoogleスプレッドシートに入力する作業が繁雑でした。 git-pr-release を使うと、これをリリースPull Requestに集約して自動化することができます。リリースPull Requestとは以下のようなものです (スクショはこのツールのPR用に作ったダミー)。 具体的なリリースまでの作業手順は以下のようになります。 開発ブランチにリリースする機能のPull Requestをmergeしていく git-pr-release を実行 merge済みのPull Requestの情報を集めてチェックリス
リリース／デプロイをめぐる刺激的な議論
ソフトウェアの開発と提供を行うほとんどの企業・組織が、ソフトウェアのデプロイ／リリースで何らかの課題を抱えている。それでも、「スクリプトを使えばいい」「スーパープログラマには自分のやりかたがある」「運用担当者の仕事がなくなるようなことはしたくない」「うちは頻繁にリリースをしないから考えなくていい」といった声が聞こえてくる。本当にそうなのか。UrbanCodeの共同創設者でCEOであり、2013年IBMに買収されたことで、現在はIBMのデプロイ／リリース製品ライン・ディレクターを務めているマチェイ・ザワツキー（Maciej Zawadzki）氏に、これらの疑問を直接ぶつけてみた。 ザワツキー氏の経験は豊富だ。UrbanCodeの活動を通じ、1996年以来、顧客組織におけるソフトウェアのビルドにかかわる問題を解決し、その後さらにリリース／デプロイの改善に取り組んできた。UrbanCodeがリリ
なぜリリース頻度を上げるのか
サービスのリリースで書いたようにネットのサービスを提供している企業は新バージョンのリリースの頻度を上げるよう常に努力しています。 リリースの頻度を上げる理由は、サービス開発の方向の軌道修正を細かく行いたいからです。少しずつサービスを改良し、その改良がユーザーにどのように受け入れられたかという反応を元に将来の開発を行っていきます。このフィードバックサイクルを短くすることによりこまめな軌道修正が可能になります。 リリース頻度が低く、リリースサイクルが長いと、その期間に加えられた変更の数が多くなり それぞれのリリースでの変更量が大きくなります。変更が多い分、リリース後の不具合発生の可能性が高くなります。また、リリース後の障害発生時の問題の切り分けも難しくなります。小さなリリースを頻繁に行うことにより、一歩一歩問題がないことを確認して次の一歩を踏み出すように、よりリスクの少ないリリースが可能になり
VOYAGE GROUP エンジニアブログ : Gitブランチによるサーバ管理
2012年09月27日10:14 カテゴリ Gitブランチによるサーバ管理 はじめまして。株式会社adingoのこんどう（@_zoo）と申します。今年の4月から新しいチームに配属され、チームのバージョン管理やリリースプロセスの整備をやっています。 今回の記事ではリリースプロセスの課題解決について、チームで取り組んだ時に出てきたGitブランチの活用方法についてご紹介させていただきます。 * 広告サービスの事例 まず、簡略ですが環境毎のサーバ構成をご紹介します。DBやその他諸々のサーバも省略し、Webサーバとビルドサーバのみ記載しています。 システム的な構成の紹介はざっくりこれだけにしておきます。 システム構成図ではサーバ台数は一台ですがサーバが数十台に増えた時のことも考えました。 1台2台のうちはいいけれど、台数が増えてくると各サーバの状態を確認という声もありました。 数十台のサーバを運用し
1日に175回もGitHubはデプロイしているだとぉ…！？ | Act as Professional
GitHubは普通の会社とどう違うのか？ リリースマネージャーがいない（いる必要がない） 週次のデプロイセットもありません（この週にこれだけの機能をまとめてリリースとかがない） 開発者とデザイナーは、早く提供できるように自分たちでデプロイする（できる）作った人達が自ら確認できて、サクッとデプロイできるのであれば、さっさと作って、ささと出してしまった方が良いに決まっています。これを実現させるために様々な工夫がされているようです。 GitHubの基本的なワークフロー The basic workflow goes like this: Push changes to a branch Wait for the build to pass on our CI server Tell Hubot to deploy it Verify that the changes work and fix a
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
大きなリリースの際にチェックすべき34のこと
以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ
Apple Days | Apple製品の発売周期まとめ
Apple製品のこれまでの発売日を元に、新製品が出るまでの周期をまとめました！
Firefox/Thunderbird 延長サポート版の提供が決定しました | Mozilla Japan ブログ
Mozilla は、以前から提案していた Firefox 延長サポート版 (ESR) の計画 を実施に移すことを決定しました。ESR は、Firefox の導入を集中管理している企業や公共機関、大学、その他法人向けに提供するものです。ESR のメジャーアップデートは年 1 回とし、その間、Web やアドオンの互換性には変更を加えずセキュリティ問題のみを修正するマイナーアップデートを、通常版 Firefox の更新と同時 (原則 6 週間ごと) にリリースします。私たちは多くの法人と協力して、最新のセキュリティアップデートに対する需要と、社内アプリケーション検証の負荷を軽減したいという要望のバランスを取れるよう、ESR の提供を企画しました。 インターネットを中心としたライフスタイルはかつてなく急速に進化しており、これを受けて Web と Firefox へより素早く革新をもたらすことが M
Continuous Deliveryを読む。2011-11-06 - 未来のいつか/hyoshiokの日記
同僚とContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))の読書会をやっている。 英語の本なので、一人で読むにはちょっと敷居が高くても何人かで読めばどうにかこうにか読了できるような気がする。きっかけとして読書会というのはいいメソッドである。 読書会のメリットは、わたしのようなものぐさでもある種のプレッシャーがかかるので、どうにかこうにか続けられるというのがあるが、それ以外でもいろいろある。 何といっても読書会のメンバー間では、言葉の定義というか概念について共通の理解が深まる。 前回レガシーコード改善ガイドを読んだとき、レガシーコードというのは、テストのないコードのことを言
完成の定義のサンプル(1)
みなさんこんにちは。@ryuzeeです。 今日は完成の定義について説明しようと思います。 完成の定義って何？チームとして定めた「出荷可能な製品」を作成するために実施しなければいけないことの一覧です。 例えば、コードを書く、ユニットテストする、統合テストをする、リリースノートを書く、などがそれにあたります。 プロダクトバックログアイテム単位での完成の定義、スプリント単位での完成の定義、リリース単位での完成の定義をすることもあります。 完成の定義はチームの成熟度や時間によって変わっていきますが、完成の定義なくしてのScrumはあり得ません。 詳しくはScrum Allianceの記事も参照してみてください。 また、あわせてHow Do We Know When We Are Done?も読んでおくとよいと思います。 事例 Scrum Allianceの記事から上述の通り、Scrum Allia
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
