gitflowを使用するときに本番ロールバックに対処する方法
私たちは、人気のある Gitflow をgit分岐モデルとして検討しており、私はこれまで好きでした。よくわからない1つのケースは、本番のロールバックです。たとえば、次のリリースで公開する予定の新機能があるとします。機能がテストされ、最終的にマスターにマージされます。自動または手動で、マスターのソースコードがビルドおよびデプロイされます。デプロイ後すぐに、重大なバグを明らかにし、すぐにホットフィックスブランチを作成します。大丈夫、これまでのところ良い。ただし、製品版を最新の正常なバージョンにロールバックします。これは、本番環境で実行されているプログラムがmasterブランチのソースと一致しないことを意味します。そして、マスターから分岐した人は誰でも、実際に機能している別のものになります。この事件にどう対処しますか？
デプロイ後すぐに、重大なバグを明らかにし、すぐにホットフィックスブランチを作成します。大丈夫、これまでのところ良い。ただし、製品版を最新の正常なバージョンにロールバックします。
誤解があります。修正プログラムを適用すると、バージョンが上がります。たとえば、機能がマージされ、バージョン1.4のタグが付けられている場合、修正プログラムを適用すると、バージョンも上がります。
その新しいバージョンは1.4.1または1.4.0.1である可能性があります。同時に、修正プログラムを開発ブランチにマージします。したがって、マスターと変更の両方がマスターにあり、現在開発中です。
次に、機能なしで新しいバージョンをデプロイします。
これは、本番環境で実行されているプログラムがmasterブランチのソースと一致しないことを意味します。そして、マスターから分岐した人は誰でも、実際に機能している別のものになります。この事件にどう対処しますか？
何もロールバックせず、機能を削除して、修正された1.4.1（またはビルドバージョンを計画的メンテナンス用に予約する場合は1.4.0.1）バージョンをデプロイするだけです。