Hotfix

Olağan değişiklikler inceleme, test ve bir sonraki sürümü bekler. Hotfix bekleyemez: kullanıcılar şu anda etkileniyor. Düzeltme olabildiğince küçük tutulur ve tam olarak production'da çalışan koddan başlanır; böylece acil sürüme ilgisiz hiçbir şey sızmaz. Yine de hızlı bir incelemeden ve en önemli otomatik testlerden geçer, çünkü aceleyle yapılıp başka bir şeyi bozan bir düzeltme olayı daha da kötüleştirir.

Gitflow'da bir hotfix branch'i main'den ya da production etiketinden oluşturulur, düzeltilir, 2.4.1 gibi bir patch sürümü olarak yayımlanır, sonra düzeltme bir sonraki sürümde kaybolmasın diye hem main'e hem develop'a birleştirilir. Trunk tabanlı geliştirmede ise düzeltme trunk'a commit'lenir ve olağan hızlı hat üzerinden dağıtılır ya da kullanılıyorsa bir sürüm branch'ine cherry-pick edilir.

İlk müdahaleyi çoğu zaman feature flag'ler ve hızlı geri almalar sağlar: bozuk özelliği kapatın ya da önceki sürüme geri dönün, sonra düzgün bir hotfix'i sakin şekilde hazırlayın. Olaydan sonra suçlamasız bir postmortem, hatanın neden production'a ulaştığına bakar ve aynı türden bir sorunun bir dahaki sefere daha erken yakalanması için testler ya da kontroller ekler.

Sık yapılan bir yanlış, hotfix'in süreci atlamanın bir kısayolu olduğunu düşünmektir. Acil durumlar için ayrı ve iyi tanımlanmış bir süreçtir. Sürekli hotfix yapan ekiplerin genellikle eksik testler ya da riskli dağıtımlar gibi daha derin bir sorunu vardır; bunu daha hızlı bir olağan hat daha iyi çözer.