1週間のリリースサイクル:これを実現するにはどうすればよいですか?


12

私の会社(3年前のWeb業界の新興企業)では、製品チームに「これは危機的なパッチになりました!」と頻繁に問題があります。(皆ではありませんか?)

これは、自己完結したエンジニアリングスタッフの生産性(および士気)に影響を与えます。経営陣は、これらの同日リクエストの頻度を減らす方法について考えることに時間を費やし、毎週リリースするソリューションを考え出しました。(以前は2週間に1回行っていましたが、通常は数日ほどずれていました。)

13人の開発者と6人のローカル/ 9人のオフショアテスターがいます。理論的には、他の開発者のいずれかから特定の専門知識を実際に必要とする作業が発生しない限り、4人の開発者(およびすべてのテスター)だけが偶数番号のリリースで作業します。各サイクルには、2日間の開発作業と2日間のQA作業が含まれます(さらに1日間のスコーピング/トリアージ/ ...)。

私の質問は:

(a)このリリース期間の長さを経験した人はいますか?

(b)このようなリリースサイクルが試みられていることを誰かが聞いたことがありますか?

(c)(a)または(b)の場合、地球上でどのように機能させますか?(避けるべき落とし穴なども歓迎します。)

(d)この取り組みが失敗した場合、どのように損害を最小限に抑えることができますか?


「危機的な仕事」とはどういう意味ですか?
Wizard79

受け取ったその日のうちにパッチを適用するように指示されたリクエスト。質問を編集して、一目でわかるようにします。
アルカアイト

回答:


8

確実に毎週、またはさらに頻繁に配信できます。現時点では通常2週間ごとにリリースしていますが、パートナーのいずれかから通知がなく、次のサイクルを待たなければ関係のないものが到着したときに機能を展開することは珍しいことではありません。今後数か月のうちのある時点で、標準として継続配信(アイテムが「完了」されるとすぐにリリースされます)に移行したいと考えていますが、まだ十分ではありません。遠い。

重要なことは、自動化されたテスト(ユニットテストとエンドツーエンドの受け入れテスト/実行可能な仕様の両方)で強力にカバーされたWebサイトが必要であることです。暗黙的にこれは、ビルドが完全に自動化されていることも意味します。受け入れレベルでは、ロボットのフレームワークを使用します。これは、キーワードアプローチのおかげで、メンテナンス可能なテストスイートを迅速に構築するのに優れています。ルックアンドフィールについては、オンサイトテスターがいくつかの大まかなチェックを行いますが、異なるブラウザー間でより徹底的なチェックを行うインドの男性もいます(BrowserLabなどのスクリーンショットを撮って、この種のことを支援するサイトがあります)。

展開を完全に自動化するわけではありません(最後のステップでは手動の介入が必要です。これは私たちにとっては慎重な決定です)-しかし、短い展開サイクルで正しいデータベース接続が使用されていることを確認するなど、すべてを自動化しますこの種のもので間違いを犯すのは簡単すぎるでしょう。

継続的な配信に関する非常に優れた最近の本がありますので、チェックしてみてください。私はそれをざっと読みましたが、まだ詳しく説明していません。私がこれまでに読んだことは、しかし私たちの経験とうまく調和しています:継続的デリバリー:ビルド、テスト、展開の自動化による信頼性の高いソフトウェアリリース

要約すると、高度に統制されたチーム、高レベルの自動化、そして最も重要なこととして、その自動化に対する非常に高い信頼が必要です。私にとっては、あなたのケースで毎週のサイクルに移行することは間違いかもしれません。テンポを上げると状況が悪化する可能性があります...


7

継続的に「危機解放」モードにいる場合は、一歩下がってコードとプロセスを再評価する方が賢明だと思います。明らかに、繰り返され続ける何らかの種類の障害があります。

真の生産規模でこれを行うことは完全には不可能かもしれませんが、少なくとも1人の上級メンバーと、開発者とテスターの他のサブセットをこの評価に専念させることは価値があるでしょう。

「一度に4つのアプローチ」は、私にとって明確な勝者のようには思えません。これは、絶えずコンテキストを切り替えることを意味し、効率がはるかに低くなります。

常に変更を急いでいる場合、それらの変更に間違いを犯し、それを行っている間に何か他のものを壊す可能性がはるかに高いことを覚えておいてください。


@Wonkoの素晴らしい答えに自分のコメントを追加できるとしたら...私たちの会社は数年かけてOPに似たようなことをしました。6人または開発者から16人に成長しました。約2年前、アジャイルに行くことにしました。アジャイル体験を備えたシニア開発者を雇い、2週間のイテレーションを切り替え、継続的インテグレーションを実装しました...私たちはまだ教科書店からは程遠いです。スイッチング、これは大きな勝利です。
DevSolo


1

経営陣は、これらの「危機的な仕事」の頻度を減らす方法について考えることに時間を費やし、毎週リリースするというソリューションを考え出しました。

あなたの管理は世界チャンピオンのように見えます...あなたのチームスピリットに投資してみませんか?あなたは彼ら自身によって問題が消えるのを見るでしょう。

(a)+(b)私見、チームの規模に応じて最大2週間。1週間は、1人の男性ショーまたは非常に小さなチーム(2または3など)で機能します。

(c)+(d)しかし、チームまたはプロジェクトの規模に関係なく、私が最初に行うことの1つは、ビルドと展開の自動化です。プロジェクトの初期の段階でそれを行うことで、数週間ではなくても数日を節約できます。

展開はワンクリックで行う必要があります。ソースからステージングへ、次にステージングから実稼働へ。これを可能にする多くのツールがあります。アリ/のNAntのような超重いものに自動ビルドメーカー

バックアップ、通知、レポートなど、ファイルの展開からデータベースのアップグレードまで、すべてを自動化できます。


ここで何を提案しているのか完全にはわかりません-問題管理が対処すべき問題はチーム精神の欠如だと言っていますか?それとも、私はこの仕事をする方法を見つけようとすることでチーム精神の欠如を示していると言っていますか(そして、成功の見通しに神経質になっています)?
アルカアイト

数行のテキストで説明されている場合、あなたの状況について客観的な意見を述べることはできません。ただし、チームの精神の欠如は、通常、あなたのような組織の多くの問題の根本原因であることに気付きました。かかわらず、私はアドレスにあなたを示唆問題、展開プロセスを自動化することは、あなたの経験を向上させること
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.