Erişim haritası çıkarın
Alan adı, barındırma, veri tabanı, bildirim sağlayıcısı ve kod deposunun sahiplerini listeleyin. Hesapların işletmenin kontrolünde olması ile ekibin günlük erişimi ayrı konulardır. Gizli anahtarları dokümana yapıştırmak yerine güvenli saklama ve yenileme yöntemini belirleyin. Ayrılan bir ekip üyesinin erişiminin nasıl kaldırılacağı da devir planının parçasıdır.
Kararın nedenini kaydedin
Bir modülün ne yaptığı kadar, neden o şekilde tasarlandığı da önemlidir. Veri modeli, temel yetkiler, entegrasyon sınırları ve bilinen kısıtları kısa karar notlarıyla açıklayın. Yeni geliştiricinin bütün görüşme geçmişini okumadan doğru değişikliği yapabilmesini hedefleyin. Dokümantasyon bir kere yazılan kitap değil, kod değiştikçe güncellenen çalışma aracı olmalıdır.
Yedek geri yüklenebiliyorsa işe yarar
Yedek alındı bildirimi, geri dönüşün çalıştığını kanıtlamaz. Uygun bir test ortamında geri yükleme provası yapın; gereken süreyi ve sorumluyu kaydedin. Silme ve saklama kurallarının yedeklere etkisini de düşünün. Yayın sonrası bir sorun çıkarsa hangi sürüme dönüleceği ve veri değişikliklerinin nasıl ele alınacağı önceden belirli olsun.
Bakımın kapsamını yazılı belirleyin
Hata düzeltme, bağımlılık güncelleme, yeni özellik ve sağlayıcı değişikliğini aynı başlık altında belirsiz bırakmayın. Destek kanalı, öncelik sınıfları ve yanıt hedefleri açık olsun. Küçük bir içerik sitesinin bakım ihtiyacı ile gün boyunca operasyon yürüten bir uygulama aynı değildir. Bütçeyi ve sorumlulukları sistemin iş üzerindeki etkisine göre planlayın.