Yazılım Kaynak Kodu ve Teknik Devir Rehberi

Her bileşen için mevcut sorumluyu, yeni yetkiliyi, konumu ve kabul kanıtını yazın. Bilgi yalnızca bir kişinin mesajlarında bulunuyorsa ekip değişiminde erişimi zorlaşır. Belgeyi kaynak kodun hangi sürümüyle ilişkili olduğunu gösterecek biçimde sürümleyin.

Geliştiricinin kendi bilgisayarında çalışan uygulama, başka bir ortamda eksik bağımlılıklar nedeniyle açılmayabilir. Çalışma zamanı sürümlerini, paket yöneticisini, derleme komutlarını ve veritabanı hazırlığını belgeleyin. Yerel dosyalara veya kişisel hesaplara bağlı adımları ortaya çıkarın.

Yeni ekip temiz bir test ortamında kurulum yaparken belgenin hangi adımlarda yetersiz kaldığını kaydetsin. Eksikleri uygulamayı bilen kişinin sözlü yardımıyla geçmek yerine belgeye işleyin. Provanın sonunda kullanılan sürüm ve çıkan sorunlar teslim kaydında yer alsın.

Tabloların adlarını bilmek iş kurallarını anlamaya yetmez. Kritik ilişkiler, veri bütünlüğü kısıtları, zaman dilimi varsayımları ve dış sistem kimlikleri açıklanmalıdır. Dosya depolama veya arama dizini kullanılıyorsa bunların veriyle ilişkisi de envantere dahil edilir.

Yedekleme kapsamının dışında kalan varlıklar olup olmadığını kontrol edin. Uygulama koduyla veritabanı sürümü uyumlu olmalıdır; bir sürümü geri almak her veri değişikliğini otomatik geri almaz. Geri dönüşün uygulanabilirliğini veri geçişine göre değerlendirin ve provayı canlıdan ayrı bir ortamda yapın.

Depo aktarımı, barındırma hesabı ve dış servis abonelikleri farklı işlemlerdir. GitHub depo aktarımında mevcut ilişkili erişimler ve bazı ayarlar korunabilir; aktarım sonrasında üyeleri, anahtarları ve otomasyonları gözden geçirmek gerekir. Depo sahibi değişti diye tüm eski erişimlerin kalktığını varsaymayın.

Ortam değişkenlerinin adlarını, amaçlarını ve hangi sistemden sağlandıklarını belgeleyin. Gerçek parolaları ve anahtarları herkese açık README dosyasına veya kaynak kod geçmişine koymayın. Gerekli gizli değerlerin güvenli aktarımını ve ortak kullanılmış değerlerin yenilenmesini sorumlu kişilerle planlayın.

Üçüncü taraf kütüphane, ücretli bileşen ve hizmetlerin lisans koşullarını kayıt altına alın. Teknik olarak bir dosyaya erişebilmek, o bileşeni her amaçla kullanma veya devretme hakkını kendiliğinden belirlemez.

“Sunucu yönetiliyor” ifadesi yerine hata kaydının nerede görüldüğünü, hangi uyarının kime gittiğini ve ilk kontrol adımlarını yazın. Dış servis kesintisi, başarısız kuyruk işi veya depolama doluluğu gibi uygulamanız için önemli olayları seçin.

Temsili bir olayda yeni ekip başarısız aktarımı kayıt üzerinden bulabilmeli, etkilenen işi ayırt edebilmeli ve tekrar çalıştırmanın yan etkisini değerlendirebilmelidir. Tekrar deneme ve geri dönüş adımları veri çoğalmasına veya kaybına yol açmayacak biçimde sınanmalıdır.

1. Yeni yetkili hesapla depoya ve test ortamına erişin.
2. Belgedeki komutlarla uygulamayı temiz ortamda derleyin.
3. Uygun test verisini yükleyip kritik akışı tamamlayın.
4. Küçük bir değişikliği kontrollü test ortamına yayınlayın.
5. Bir hata kaydını bulup yedek ve geri dönüş yolunu doğrulayın.
6. Eksikleri kapattıktan sonra eski erişimleri ve destek geçişini gözden geçirin.

Kabul testleri ile iş akışlarını; yazılım şirketi seçimi ile teslim sorumluluklarını değerlendirin. Domain ve kurumsal site hesapları için web sitesi sahipliği ve devir rehberindeki ayrı envanteri kullanın.

Yazılım devralma kontrol listesi mevcut sistemin durumunu ve bilinmeyenlerini değerlendirir. Bu rehberdeki teslim paketiyle birlikte kullanarak inceleme bulgularını geçiş planına bağlayın.

Yazılım bakım anlaşması rehberi üzerinden hata giderme, izleme ve destek sorumlularını tanımlayın. Devir tamamlandıktan sonra olayları kimin takip edeceği belli olsun.