RAD環境でのリリース品質を改善する簡単な方法
ここで少し背景を説明します。私たちは、RAD大規模な非ソフトウェア会社の内部ソフトウェア開発を担当する開発者の小さなチーム（5名）です。「内部ソフトウェア」はデスクトップとは異なります。 MSSQLサーバーをバックエンドとして使用するNETアプリケーションPython MS Wordドキュメントとテンプレートのバックグラウンドで実行されるスクリプト-テクノロジーの動物園。
チーム全体は、ユーザーから要件を取得し、それをコード化し、テストして、本番環境に展開できる万能者で構成されています。本番環境のソフトウェアは、別のチームによって管理されていますが、通常、問題が発生した場合に簡単に介入できます。
これまでのところすべては良さそうに聞こえますが、RADチームであることは頻繁にリリースする必要があり、1つまたは2つのアプリケーションの新しいバージョンをリリースすることなしには、一日が過ぎません（またはスクリプト、更新されたWord文書、C++コンソールアプリなど）を本番環境に組み込むことができます。開発テストを行い、エンドユーザーがUAT環境でソフトウェアを実行できるようにして、エンドユーザーを関与させます...
...とにかく、バグは本番環境に忍び込んでいます。ユーザーはこれらのバグと時々の不安定性が本当に欲しいものを手早く得るために払っている代償であることを理解していますが、同時に私たちは考えさせられました-おそらく私たちは開発またはリリースのプラクティスを改善して、ソフトウェアを使用して、新しい機能を追加するときに発生するバグの数を減らします。
良い点-そもそもプロセスの多くはないので、改善を開始するのは簡単です。悪い点-小さいRADチームではないので何か大きなものを実装するのに本当に多くの時間とリソースがありますが、私たちは以下のイニシアチブについて考えており、フィードバック、ヒント、ヒント、提案を歓迎します。
現在、一部のアプリケーションは、ユーザー受け入れテストをバイパスして、開発者テストの直後に製品版にリリースされています。その慣行は中止する必要があり、小さな変更でもエンドユーザーがテストする必要があります。各アプリケーションには、エンドユーザーから選択された専用のベータテスターがあります。ベータテスターが新しいリリースを承認した後でのみ、テスト環境から本番環境に昇格します。
コードレビューは行いませんが、変更セットをチェックインする前にコードレビューを開始します。私は「ロールアウトレビュー」についても考えていました。基本的に、開発者の1人は、ソフトウェアのロールアウト（バイナリのコピー、構成の更新、データベースへの新しいテーブルの追加など）を行っている他の開発者と一緒に座っていなければなりません-通常はそれだけです。 5〜10分かかるため、「ロールアウトレビュー」にそれほど時間はかかりません。
新しいリリースがバグが多く、本番環境から引き離して、以前の適切なバージョンに置き換えることができることが証明されている場合に、ロールバック時間を最小限に抑える方法。すべてのリリースの履歴を（バイナリとして）保存して、1つのバージョンに簡単に戻れるようにします。「新しくリリースされたバイナリを以前のバージョンのバイナリで上書きする」のは簡単ですが、それでもエラーが発生しやすい手動プロセスです。また、「ロールバックが失敗し、システムがバグの代わりに使用できなくなる場合はどうなるか」を要求することもあります。
これは私たちがアイデアを使い果たした場所であり、私たちはこれらについてあなたのフィードバックを得たいと思います、そしてあなたがいくつかの簡単なリリース/開発プロセス改善のアドバイスを共有できれば-それは素晴らしいでしょう。
素晴らしいテーマに触れるための+1。 「早期リリースを頻繁にリリースする」という開発ラインを行うと、物事は本当のペースで進み、勢いが増すにつれ、そのような多くの問題が（説明したように）発生します。最悪の恐怖は、人々がスピードを良い仕事の敵だと考えるときです。
私はこれについて非常に限られた文献を見たことがありますが、これは私たちが実践することで間違いなく役立ちます：
1。効果的なバグ追跡
バグ追跡をより効果的にする-私たちがすることは、バグと目盛りのリストを保持するだけでなく、クローズ時に、「問題は再現可能か」、「これは永続的な解決策ですか？」または作業修正？」、「トラブルの根本原因は何ですか？」これにより、前回このバグが表示されたときに何が起こったかを知ることができます。これは、バグが頻繁に繰り返されないようにするための鍵です。
2。主要なフォールバックポイントを定義する
私たちは皆、バグが到着することを知っているため、最も頻繁に機能する効果的なフォールバックを提供する必要があります。どこでも最も信頼できる方法で機能する最も一般的なリリースを何度も繰り返します（この例では10分の1の比率で）。リリースの合計数は多くなる可能性がありますが、何か問題が発生した場合は、フォールバックはほとんど選択されず、それ以上フォールバックする必要はありません。最良のフォールバックを知る最も簡単な方法の1つは、本番環境でほとんど問題なく実行されている最も古いリリースを確認することです。
。危険で安定した、または小さなバグ修正リリースを区別する
アルゴリズムが大幅に変更されたことがわかった場合、すべてが予見されるわけではないシナリオでバグが侵入する可能性が高くなります。問題が非常に小さい（またはよく理解されている）だけでなく、リスクもほとんどない場合があります。同じリリースで、このような機能と単純なバグを[〜＃〜]しない[〜＃〜]しないでください。常に最初に小さなバグを修正し、必要な場所に移動する必要があります。 特別な機能セットの専用リリースを作成することで、その機能を非推奨にできますが、他のすべての重要なバグは以前のリリースで修正されています。
4。重要な機能開発のための分岐
デザインに影響を与える変更を関連付けるものは、ブランチで個別に実行する必要があります。小さなバグと比較して、大きな開発はすぐには完了しません。まだ使用されていない機能に関連する「部分的な」作業である中間コミットを導入する場合-潜在的なバグ導入領域です。機能のすべての作業がアトミックに完了した場合に発生しなかったであろうバグ-したがって、これらはブランチがある場合に解決する必要のないバグです。
5。常にテーマベースのリリースを計画する
多くの場合、さまざまなリリースでさまざまなバグが発生します。ただし、類似のモジュールに影響するバグ（および機能）を整理すると、繰り返し作業が容易になり、その作業に起因するバグの数を最小限に抑えることができます。常に事前にリリースロードマップを十分に準備してください。バグはどんどん流れ込みます-そして、それは異なるターゲットリリースに分類され、良いリリースで一緒に撃たれる良いバグのグループを最適に持っています。同様のバグを組み合わせると、矛盾するシナリオに関する洞察が常に得られます。
6。新しいリリースを最初に数人の顧客に拡張する
私たちのケースでは、最初にいくつかのサイトでテストし、他のすべてのサイトには、要求があった場合にのみリリースが適用されます。多くの場合、一部の（またはほとんどの）ユーザーは、安定版リリースから別の安定版リリースのみにジャンプします。
7。回帰テスト
収集されている一連のバグに沿って-回帰スーツを構築します。また、可能であれば、リリース候補が実際にリリースになる前にテストされる最小限の認定基準となる、重大なバグとテストを最も重要なものとしてマークします。
8。一時停止して反映
多くのことが全速力で進むとき、少し休憩をとる時間があるはずです-少し間を置いて、機能的に良くないリリースをしてください。実際、しばらくの間リリースの休日があります。 （継続時間は周波数に反比例します）。たとえば、機能の観点からは何も新しいことを実現しない、いわゆる「クリーンアップ」リリースが何度もありますが、コードの保守を維持するのに役立ちます。そのようなリリースのほとんどは、それ以前の履歴をほとんど思い出せない素晴らしいフォールバックポイントです。
9。おそらく最も奇妙な
これはしばしば実装するのが難しいと思いますが、確かに良いトリックです。特定のモジュールの所有者を入れ替えます。人々がコードレビューを行うように依頼されたとき、この実践からはあまり出てきません。しかし、その新しいコードに真剣に取り組む必要がある場合、作成者を入れ替えると、潜在的な「悪い」病気がコードを汚染し始める前にすぐに気づきます。もちろん、これにより速度が低下します。ただし、これを頻繁に行うと、人々がコードのさまざまな部分を習得し、他の方法では教えるのが非常に難しい製品全体について学ぶ可能性があります。
10。最後ですが、重要です
ホワイトボードに頻繁に戻る方法を学びます。 この機能が私たちの最も初期の設計の一部であったとしたら、そのときの設計をどのように考えましたか？時々、インクリメンタル作業の最大の課題は、最初に構築した機能の順序に制約されすぎて、基本に戻れないことがよくあることです。コツは、この新しい機能やシナリオに対応するのではなく、どのように一般化するかを見続けることです。これには、デザインを最新の状態に保つことが必要であり、これは私たちが頻繁に設計図に戻る場合にのみ起こります。また、新世代のプログラマーが加わると、彼らは単にパッチを置くのではなく、思考のタンクの一部になります。
[〜＃〜]編集[〜＃〜]
11。回避策と設計のギャップを追跡します。
多くの場合、バグを修正して本番環境でリリースするというタイムラインのプレッシャーにさらされています。ただし、バグが設計レベルにある場合、変更する必要のある事項はかなり多くありますが、多くの場合、締切に間に合わせるためにいくつかのショートカットで修正します。これは[〜＃〜] ok [〜＃〜]です。ただし、そのようなソリューションを回避するソリューションが複数増えると、コードは脆弱になります。すでにいくつの設計ギャップが生じているかについての特別な記録を保管してください。通常、プロジェクトマネージャーとタイムラインを交渉するときは、生産を節約するためにこれをショートカットで提供することを彼/彼女に約束するのが最善ですが、恒久的な解決策を得るためのタイムラインとリソース。
私も小さな開発チーム（2人だけ）で働いており、あなたが言及した同様の問題が発生しました。私たちの主な問題は、両方が別々のタスクに取り組む傾向があり、タスク/機能を完了し、それをテストし（開発者のみがテスト）、迅速にリリースすることが一般的になりすぎていることです。これにより、多くの小さなリリースが発生し、ユーザーはテストで簡単に見つけられるはずの小さなバグを報告しました。
プロセスを改善するために、まず かんばん ボードを導入しました。ボードは最初は非常にシンプルで、数列しかありませんでした（ホワイトボード、インデックスカード、色付き磁石を使用してセットアップ）：
バックログ|すること|できた
しかし、これは急速に進化して実際のプロセスを反映しています。
バックログ|開発|開発。テスト| UAT |完了|リリース済み
ボードに加えて、各タスク/機能は別の開発者（および機能を実装した開発者）がテストする必要があるというルールがあります。したがって、カードが「完了」列に到達するまでに、少なくとも2人の開発者によってテストされ、ユーザー受け入れテストも行われているはずです。
かんばんの使用には他にも多くの利点があります。私たちにとっては、コミュニケーションを改善し、知識を共有するのに役立ちました。私たちは両方とも各タスクにある程度関与しているからです。また、リリース/完了の準備ができているタスク/機能を正確に確認できるため、リリースプロセスも改善され、他のタスクがすぐに完了することがわかっている場合は、リリースを保留することができます。チーム外の人にとっては、ボードはまた、私たちがスケジュールしたタスク、進行中の作業、最近リリースされたものを確認するためのクイックリファレンスとしても機能します。
余談ですが、現在取り組んでいるカードにフラグを付けるために色付きの磁石（開発者ごとに1つ）を使用しますが、別のオプションは、開発者ごとに1つスイムレーン（行）を追加し、関連するスイムレーンにカンバンカードを配置することです。繰り返しますが、これは各開発者が現在取り組んでいることを確認するためのクイックリファレンスとして役立ちます。
その他の役立つリンク：
ソフトウェア開発に適用されるかんばん：アジャイルからリーンへ
願わくば、かんばんはあなたの質問のポイント1に対処するでしょう。コードレビューに関しては、開発テスト段階でこれを行うため、レビュー後に必要な変更はUATに進む前に再度開発テストされます。ロールバックは環境に依存しますが、現在のファイルの名前を変更して中央サーバーから新しいファイルにコピーするバッチファイルを使用してアプリケーションファイルをターミナルサーバーに展開し、バックアップ（以前のファイル）を中央の場所に配置することで、かなり簡単にロールバックできます。スクリプトを再実行します。
ソフトウェアの品質に影響を与えるプロセスの問題があることを知っていることをすでに確認しました。この質問はさまざまな答えを引き起こしますが、私の提案は、ソフトウェアエンジニアリングのトピックを見て、何を試すかを学ぶことですメインの開発者は、その領域でますます多くのことをしていることに気づいています。いくつかの優れたリソースを読んで、自分をキックオフすることをお勧めします。頭に浮かぶいくつか：
- リーンソフトウェア開発 メアリーとトムポッペンデイックは、「無駄」を特定する方法、およびプロセスをより効率的かつ効率的にするためにプロセスを変更する際に何をすべきかを学ぶことに興味がある人に、優れた資料を提供しています。
- Head First Software Development Dan PiloneとRuss Milesによる一見は、これらの「ダミー用」の本の1つに少し似ていますが、混沌としたプレゼンテーションスタイルの少し先を見ると、ほとんどの情報が含まれていますソフトウェアエンジニアリングの基本に関連し、テスト駆動開発について簡単に書いています。
- BDDの紹介 は、Behavioured Driven Developmentへの取り組みに関するDan Northのページです。おそらく BDD Wiki をお勧めします。これらはBDDのスターターリファレンスであり、おそらくあなたはツールとフレームワークを調べて支援することになるでしょう。理解しておくべき重要なことは、BDDは効果的にTDDをより高い概念レベルに引き上げたものであることです。仕様について考えるのと同じようにテストを考えることができ、仕様を書くときに使用するのと同じ言語でテストすることができます。フレームワークは通常、他の単体テストフレームワークと統合されているため、テストでBDD構文のメリットが必ずしも得られない場合は、両方のメリットを最大限に活用できます。
- ウィキペディアのアジャイルソフトウェア開発に関する記事 は、アジャイルソフトウェア開発に関する優れた入門書であり、開発コミュニティのより尊敬される人々による、多数の有用な参照や記事へのリンクを提供します。
仕事のやり方を改善するためには、自分が完全にオープンマインドであり、あなたが見つけるかもしれない特定の概念に固執することなく、あなたが行うことを改善することを学ぶために、自分の快適ゾーンの外へと進んで進んでいくことができるようにする必要があります。につかまってより快適です。個人的な経験から言えば、これはおそらく、最も難しいこと、または他の人を励ますことです。
積極的に変化を求めていると感じていても、変化は最高の状態では難しいので、私が実際にできる最高のアドバイスは、長年にわたって開発に慣れているさまざまなアジャイル手法を見て慣行に慣れることです。これらは最も重要であると考えられており（例：単体テスト、継続的インテグレーション、リファクタリングなど）、あなたとあなたのチームが最も快適に感じるものに最も近いと思われる方法論を選択します。決定を下したら、チームがどのように働きたいかを適切に満たすようにプラクティスと開発プロセスを調整します。リーンプリンシパルと、チームが最大の価値を生み出せるように働きたい方法を念頭に置いてください。無駄を最小限に抑えます。最後に、常に楽しみにしていて、常に時間の経過とともにプロセスの改善を追求し、プロセスに変更を段階的に導入するのに十分なだけ、自分の選択を推測し、飲み込むことが容易になり、第二の性質になるようにします。時間が経つにつれ、プロセスは徐々に改善されていきます。
プロセスを調整するだけでよいと感じても、ツールチェーンがニーズに完全に対応していないことに懸念がある場合は、おそらくそこでの改善を検討してください。少なくとも、継続的インテグレーション統合製品（Continuum、Cruise Control、Hudsonなど）と問題追跡システム（Jira、Redmineなど）は、ビルドおよびリリースプロセスの一部を自動化するのに役立つ優先事項である必要があります。バグや機能のリクエストを抑えるために。
現実は、プロセスがいかにRAD=であっても）、チームにとって「正しい」ものを得るために時間を費やさなければ、問題は次第に大きくなるだけです。時間に応じて、利用可能な時間の認識はそれに応じて縮小します。大きな時間のプレッシャーの下では、大きな変更は通常問題外ですが、赤ちゃんを連れて行くのに役立つシステムを配置するために、少し「ゆらぎの部屋」を用意してください理想的な方法論というチームのビジョンに向けたステップ。
欠陥について聞くときはいつでも、私の最初の質問は、欠陥がどこで発生し、どこで検出され、削除されるかについてです。 欠陥除去効率 は、これを測定および追跡するための良い方法です。欠陥の発生場所を把握し、それらのフェーズでプロセスを改善することで、プロジェクトの時間とコストを削減できます。欠陥を注入ポイントに近づけて修正する方が安価であることはよく知られているため、欠陥の原因がわかったら、アクティビティの変更を確認してこれらのフェーズを改善できます。
欠陥がどこから発生しているのかについての情報が得られたら、適用したい技術や技術を正確に調べることができます。要件、設計、およびコードのレビュー、自動テスト、静的分析、継続的統合、およびより広範なユーザー主導のテストは、どのフェーズが欠陥を生成するかに応じて、検討する必要があるオプションです。
コードレビューの要望をさらに広げるには、モジュールの優先度とリスクに基づいて、さまざまなレベルのコードレビューも検討する必要があります。リスクが低く、優先度の低いモジュールは、コードレビューをまったく必要としない場合もあれば、別の開発者が自分でコードを読み取ってコメントを提供するだけの単純なデスクチェックだけで機能する場合もあります。他のコードレビュー手法には、ペアプログラミング、ウォークスルー、批評、さまざまな数の開発者による検査が含まれます。
ロールバックの目的で、ある種のスクリプトを使用してそのプロセスを自動化し、より速く、エラーが発生しにくくすることを検討します。完璧な世界では、ロールバックする必要がないように、出荷された製品の品質を向上させたいと思います。これを達成できます。ただし、この機能を備えていることは良い考えかもしれませんが、可能な限り苦痛をなくします。
他の人が指摘したように、 回帰テスト を追加すると、将来同じ欠陥が現れるのを防ぐのに役立ちます。ただし、新しい欠陥が発生した場合は、クラスとメソッドの事前条件、事後条件、および不変条件を指定するコードに アサーション（別名コントラクト）を追加するときがきたかもしれません。 =
たとえば、メソッドが10〜25の数値のみを受け入れることができるクラスがある場合（これは前提条件と呼ばれます）、メソッドの先頭にassertステートメントを追加します。このアサーションが失敗すると、プログラムはすぐにクラッシュし、その失敗の原因となった一連のメソッドをたどることができます。
Python、PHPおよび他のプログラミング言語は動的に型付けされ、メソッドに多くの条件を追加しません。何かが機能するために必要なのは、特定のメソッドを実装することだけです。さらに多くのものが必要だと思います。メソッドの条件。メソッドがその環境で実際に機能することを確認するために定義およびテストする必要があります。
C/C++プログラムの場合、メモリ割り当てをテストするためにアサーションを追加すると、プログラムのメモリリークの数を減らすのに非常に役立つことがわかりました。