新しいリリースプロセスをデプロイした - fujimuradaisuke's blog
今やっているサービス、ちょっと障害が増えてきたので、リリースプロセスを変えました。 ざっくり言うと、今までmasterを全部デプロイしていたのを、金曜日以外の毎日一回、手動の確認をしてリリースするようにした。実際のドキュメント(Wikiです)を日本語にしてダイジェストで紹介してみようと思います。 ちなみにこのサービスは複数のアプリケーションがあって、今回対象にしたのはそのうちの主要な3つのみです。 ブランチ戦略 developを本流として、そこにトピックブランチからプルリクエストを出す。masterは常に本番環境に自動的にリリースされる*1 急ぐときはHotfixとしてmasterに直接プルリクエストを出してもOK*2。 リリース手順 HipChatで「リリースするよ」ってアナウンスする developからmasterにプルリクエストを出す HipChatでHubotに頼むと、Jenkin
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
毎日コードを書くこと - snowlongの日記
ワザノバで紹介されていたKhan AcademyのJohn Resigが投稿した Write Code Every Dayの翻訳です。 訳がおかしいなどの指摘をいただけると大変助かります。 去年の秋、自分のプロジェクトのコーディングを始めたんだけど、あまり進捗がよくなくてKhan Academyの仕事の効率を犠牲にすることなしに作業をすすめる方法を見つけらずにいた。 自分のプロジェクトへの取り組み方にはいくつかの問題を抱えていた。 私は週末にプロジェクトに取り組むことを優先し、平日の夜は時々といった具合だった。 自分にとってはその戦略は効果的ではなかったことが今ではわかっている。 週末の間も仕事と同じくらいの高いクオリティでプロジェクトに取り掛かり完成させるという作業は信じられないほどのストレスだった。（そして、うまく行かなかったら失敗したような気分だった。） 週末にいつも予定が空いている
失敗プロジェクトの通夜 - Strategic Choice
どういうこと？心血を注いだプロジェクトが中断されたときは、「プロジェクトの死」を悼んで、「通夜」を開催します。どうして？仕方のない外的要因のせいであっても、チームにとって、心血を注いできたプロジェクトのキャンセルは、特に士気を下げる原因となります。キャンセルの裏にある事情を、チームが理解しているかどうかは、さほど問題ではありません。とにかく、悲しい気持ちになるのです。無力に感じたり、無気力に陥ったり、時には裏切られたように感じます。チームには、即座に始めなければならない次のプロジェクトがあったとしても、なんらかの休憩は必要です。です。最悪、チームメンバーは辞めてしまうかもしれません。プロジェクトがキャンセルされたのは、自分たちのせいではないにも関わらず、成功したプロジェクトにしか、報酬は与えられません。これは、きわめて強い不公平感を生む可能性があります。どうすれば？失敗したプロジェクトのた
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
リファクタリング―プログラムの体質改善テクニック読んだ - 銀の人のメモ帳
リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (307件) を見る 残念ながらピアソン桐原から出版されていたので、現在は手に入りにくいんだけど、読んだ。 内容的には、リファクタリング手法のカタログみたいな感じだと思う。５章くらいまでは、導入とか、リファクタリングの心構えみたいな事が書いてある。 リファクタリングをするときに「いつすべきか？」というのが問題になると思うんだけど、この本では、機能を実装するときにその周辺をリファクタリングするといいと書いてあった。これは「動いてるものは触るな」っていう考
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
顧客に価値を届ける、ってなんだっけ - (define -ayalog '())
2013-12-09 顧客に価値を届ける、ってなんだっけ 開発 日記 最近、@syobochimのブログを読んでいたら、こんな言葉が書いてあった。 顧客に価値を届けたい。 私はいま、価値届けられてるんだろうか。 アジャイルサムライを読んだら意識高まってつらい - そこに仁義はあるのか(仮) 僕はどうだろうか。今のプロジェクトはありていに言えば"炎上"している。 そんな中で「誰の考え方が一番正しい」のか分からなくなった。ので、今日はそんな話を書いてみようと思う。 この話の登場人物 あやぴー 僕です。 マツダさん 僕と同じ会社の先輩。エンジニア歴10年位。 モリさん 僕と同じ会社の上司にあたる人。エンジニア歴20年位の大ベテラン。 イノウエさん 元請けの会社に8月くらいに中途で入社したエンジニアさんで立場的にはプロジェクトリーダー(PL)的な感じ。転職するまでPL1とかVBとかのお仕事を
JS 大規模プロジェクトの管理手法 – ロードオブナイツの実例紹介
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
【告知】「チケット駆動開発」ハンドブックを出版します - プログラマの思索
2012/8/24に@sakaba37さんと「チケット駆動開発～プロジェクトを成功に導くための「現場からの改善」提案を完全網羅」を出版します。 前作「Redmineによるタスクマネジメント実践技法」に続くチケット駆動開発の解説本になります。 過去5年間、チケット駆動開発とは如何なるもので、一体何ができるのか、という根本的な問題をずっと考えてきた結果を全て書きました。 元々は@machuさんがTracのチケット管理から提唱したアイデアを参考にして、故意にそのアイデアを拡張して、Redmine上でアジャイル開発を実践できるように、自分なりのノウハウを詰め込みました。 その後、チケット駆動開発について講演したり、コミュニティで議論しながら、アジャイル開発だけでなく、技術や開発プロセス全般、ソフトウェア工学など色んな観点で分析するように努めてきました。 そして、チケット駆動開発に関する技法や適用方
アジャイル手法によって生産性が上がりプロジェクトは成功するか？（いいえ） - 勘と経験と読経
ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの（わたしの）プロジェクトにも導入すべき？ その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバ
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書 始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！ 1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。 これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視
テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる, tDiary 3.0.2 リリース - 会長@腹部日記(2011-04-29)
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
投げだしたいプロジェクトをどうするか。 島国大和のド畜生
■悪い奴らは来なかった(レジデント初期研修用資料さん) 要するに「経験に裏打ちされないロジックに意味はない」という内容として読んだ。 事実そう思う。 批判は簡単だし、批判している方は自分が批判され無いから気持ちが良い。 だけどそこには実が無い。 言うは易し。行うは難し。ネットは口先だけだから居心地いいけどやはり実が無い。 人の行動のアラを探すのは簡単だが、自分の行動にアラが無いのとは別の話だ。 この辺を読んで思った全然関係の無い話をうにゃうにゃと書く。 ■目の前にあるスパゲティなコードをどうするか。 プロジェクトを引き継ぎました。継ぎ足し継ぎ足しで運用していてグズグズになったプログラムがあります。 さてどうする。 大抵のプログラマはすべて書き直したい欲求に駆られる。 問題のあるプログラムの難所を探すより、問題の無いプログラムをゼロから書いた方が気持ち良い。 だがこの試みは大抵失敗に終わる。
プロジェクト推進者のための議事録の書き方 - 人と組織と、fukui's blog
2011年02月07日 02:53 カテゴリプロジェクトデザイン プロジェクト推進者のための議事録の書き方 Posted by fukuidayo Tweet プロジェクトを設計（デザイン）し、前に進める。という仕事に取り組み始めてから、ありがたい事に多くの仕事の相談や依頼を受けるようになった。やってみて感じるのは、企画するだけでなくて、ものごとを確実に前に進めてくれる人をどこの企業も求めているんだなー、ということ。 プロジェクトを設計し、前に進める。というと大層なことをやっているように思えるかもしれないけれど、実は僕がやっていることは本当に単純で、 ・アジェンダをつくり ・会議をファシリテートし ・議事録を作成する ということをしているだけだ。もちろんプロジェクトを円滑に進めるために必要であれば、情報共有やプロジェクト推進のツールを提供したりもするけれど、基本的には無料で利用でき、汎用性
ゆーすけべー日記
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
