RAD環境でリリース品質を改善する簡単な方法
ここに少しの背景があります-私たちは、大規模な非ソフトウェア会社の内部ソフトウェア開発を担当するRAD開発者の小さなチーム（5人）です。「内部ソフトウェア」は、MSSQLサーバーをバックエンドとして使用するデスクトップ.NETアプリケーションと、バックグラウンドで実行されるPythonスクリプトからMS Word文書やテンプレートに至るまでさまざまです-技術の動物園。 チーム全体は、ユーザーから要件を取得し、コードを作成し、テストし、運用環境に展開できるすべてのアロンダで構成されています。本番環境のソフトウェアは、別のチームによって管理されていますが、通常、何か問題が発生した場合は簡単に介入できます。 これまでのところはすべて良さそうですが、問題があります-RADチームであるため、頻繁にリリースする必要があり、1つまたは2つのアプリケーションの新しいバージョンをリリースせずに1日を過ごすことはできません（または、スクリプト、更新されたWordドキュメント、C ++コンソールアプリなど）を本番環境に追加します。開発テストを行い、エンドユーザーがUAT環境でソフトウェアを実行できるようにすることで、エンドユーザーも関与させます... ...しかし、バグはとにかく生産に忍び込んでいます。ユーザーはこれらのバグと時折の不安定性が本当に欲しいものをすぐに手に入れるために支払う価格であることを理解していますが、同時に考えさせられました-おそらく開発やリリースのプラクティスを改善して安定性を改善できるかもしれません新しい機能を追加するときに導入するバグの数を減らします。 良いこと-そもそもプロセスがあまりないので、改善を開始しやすいはずです。悪いこと-実装する時間とリソースがあまりない小さなRADチームであること大きなことですが、次のイニシアチブについて検討しており、フィードバック、ヒント、ヒント、提案を歓迎します。 現在、一部のアプリケーションは、ユーザー受け入れテストをバイパスして、開発者テストの直後に本番環境にリリースされています。その慣行は中止されるべきであり、小さな変更でさえエンドユーザーがテストする必要があります。各アプリケーションには、エンドユーザーから選択された専用のベータテスターがあります。ベータテスターが新しいリリースを承認した場合のみ、テストから実稼働環境に昇格されます。 コードレビューは実施しませんが、変更セットをチェックインする前にコードレビューを開始します。また、「ロールアウトレビュー」についても考えていました。基本的に、開発者の1人がソフトウェアロールアウト（バイナリのコピー、設定の更新、データベースへの新しいテーブルの追加など）を行う他のウォッチと一緒に隣に座っている必要があります-通常は5〜10分かかるため、「ロールアウトレビュー」の時間はあまりかかりません。 新しいリリースが、本番環境から撤退し、適切な以前のバージョンに置き換えられるほどバグが多いことが証明されている場合に、ロールバック時間を短縮する方法。すべてのリリースの履歴を（バイナリとして）保存して、1つのバージョンに簡単に戻せるようにします。また、「新しくリリースされたバイナリを以前のバージョンのバイナリで上書きする」のは簡単ですが、エラーが発生しやすい手動プロセスです。また、「ロールバックが失敗し、システムがバグの代わりに使用不能になる場合はどうするか」を時々要求します。 ここでアイデアを使い果たしました。これらについてのフィードバックを受け取りたいと思います。簡単なリリース/開発プロセスの改善アドバイスを共有できれば、それは素晴らしいことです。