Yazılım proje devri: Kaynak kodla birlikte ne teslim edilmeli?

Yeni ekip kod deposunu açıyor, kurulum komutunu çalıştırıyor ve ilk soruyla karşılaşıyor: Hangi veri tabanı sürümü kullanılacak? Biraz sonra ödeme bildirimlerinin başka bir sunucudaki göreve bağlı olduğu anlaşılıyor. Yönetim paneli çalışsa da gece raporları üretilmiyor. Kaynak kod teslim edilmiş olabilir; yazılımın işletilmesine yarayan bilgi ise hâlâ eski ekibin elindedir. Yazılım proje devri bu farkı kapatmalıdır. Teslimin ölçüsü, bir klasörün gönderilmesi değil, yetkili yeni ekibin sistemi anlaşılır koşullarda sürdürebilmesidir.

Bu rehberde varsayımsal bir servis işletmesinin özel yazılımını başka bir bakım ekibine devrettiğini düşünelim. Uygulama müşteri taleplerini topluyor, görev atıyor ve günlük rapor hazırlıyor. Anlatılan adımlar gerçek bir müşteri vakası değildir. Aynı yaklaşım bir e-ticaret uygulamasına veya kurumsal portala uyarlanabilir; fakat finansal işlemler, kişisel veri ve dış entegrasyonlar için kabul koşulları ayrıca belirlenmelidir. İşletme sahibi, mevcut geliştirici ve devralacak ekip ortak bir teslim planına ihtiyaç duyar.

Önce neyin devredildiğini tarif edin

“Yazılımı teslim edeceğiz” cümlesi, tarafların aynı şeyi anladığını göstermez. Uygulamanın hangi modülleri kapsadığı, hangi ortamların bulunduğu ve hangi hizmetlerin dışarıdan alındığı bir envantere yazılmalıdır. Müşteri portalı ayrı bir depoda, raporlama aracı ayrı bir hesapta olabilir. Mobil uygulama varsa mağaza hesabı da gündeme gelir. Her varlık için teknik konum, işletme sahibi, erişim sorumlusu ve son doğrulama tarihi kaydedin. Parolaları bu envantere eklemeyin; yalnızca güvenli erişim yöntemini belirtin.

Devir sırasında geliştirilmeye devam eden işler için ayrıca sınır çizin. Hangi sürüm teslim edilecek, hangi hata bakım kapsamında kalacak, hangi özellik henüz kabul edilmedi? Bu ayrım yapılmazsa çalışan sistemle gelecek planı aynı teslim belgesine karışır. Bir modülün ekranda görünmesi, iş kurallarının tamamlandığını kanıtlamaz. Açık işleri durumlarıyla birlikte listeleyin. Teslim tarihinde mevcut olan davranışı ve daha sonra kararlaştırılacak geliştirmeyi ayrı satırlarda tutmak, yeni ekibin başlangıç tahminini daha güvenilir kılar.

Kaynak kodun canlı sürümle ilişkisini gösterin

Bir arşiv dosyasının içinde kod bulunması yeterli değildir. Canlıda çalışan sürümün hangi değişiklik kaydına karşılık geldiği anlaşılmalıdır. Kod deposunun geçmişini, sürüm etiketlerini ve çalıştırma talimatlarını teslim kapsamına alın. Yayınlanan dosyalarla depodaki kod farklıysa farkı açıklayın. Örneğin sunucuda elle düzeltilmiş bir rapor sorgusu depoya aktarılmamış olabilir. Bu fark görünmez kalırsa yeni ekip ilk yayında eski hatayı yeniden üretir. Devir incelemesi böyle sessiz ayrışmaları bulmak için iyi bir fırsattır.

Üretilen dosyalarla kaynak dosyaları da ayırın. Sıkıştırılmış tarayıcı dosyaları, düzenlenebilir tasarım kaynaklarının veya derleme yapılandırmasının yerini tutmaz. Hangi komutun hangi çıktıyı ürettiğini, gereken araç sürümlerini ve bağımlılık kilit dosyalarını açıklayın. Eski geçici dosyalar arasında doğru sürümü tahmin ettirmeyin. Devralan kişi temiz bir kopyadan çıktıyı yeniden oluşturabilmeli ve neyin değiştiğini karşılaştırabilmelidir. Bu çalışma, bakımın belirli bir geliştiricinin bilgisayarına bağlı kalmasını azaltır.

Temiz ortamda kurulum yaptırın

Kurulum belgesinin gerçek sınavı, belgeyi yazmayan birinin onu kullanmasıdır. Yeni ekip erişimi sınırlı bir test ortamında depoyu alsın ve adımları izlesin. Gerekli çalışma zamanı, veri tabanı, önbellek ve dosya depolama bileşenleri açıkça belirtilsin. Örnek ortam dosyasında değişken adları bulunsun, gerçek sırlar bulunmasın. Hangi alanın zorunlu olduğu, hangi değerin ortamdan ortama değiştiği anlatılsın. Kurulumun bir aşaması yalnızca sözlü açıklamayla geçilebiliyorsa, o açıklama belgeye dönüştürülmelidir.

İlk yönetici hesabının oluşturulması ve başlangıç verilerinin yüklenmesi de kurulumun parçasıdır. Örnek müşteri verisini canlı kayıtlarla karıştırmayın. Test verisinin nasıl ayırt edileceğini ve temizleneceğini açıklayın. İşletmemiz için görev durumları başlangıçta tanımlanmadığında ekran açılabilir ama yeni talep ilerletilemeyebilir. Dolayısıyla yalnızca giriş ekranını görmekle yetinmeyin. Örnek bir talep açın, görev atayın ve raporda sonucunu bulun. Başarılı kurulumun ne anlama geldiği bu küçük iş akışında görünür olur.

Hesap sahipliğiyle kullanım yetkisini ayırın

Alan adı, barındırma, kod deposu, bildirim hizmeti ve yedek hesabının sahibi işletme tarafından bilinmelidir. Geliştiricinin bu hesapları yönetmesi, hesapların kişisel e-posta adresine bağımlı olması gerektiği anlamına gelmez. İşletmeye ait yetkili hesaplarla erişimin sürdürülebilirliğini kontrol edin. Bir kişinin işten ayrılması hâlinde kurtarma süreci ne olacak? Faturalama bildirimi kime gidecek? Teknik erişim kadar sözleşme yenileme ve ödeme sorumluluğu da sürekliliği etkiler. Her hesabın gerçekten kullanılabilir olduğunu doğrulayın.

Yetki devrinde herkese yönetici rolü vermek kolay görünür, fakat sorunu ileride büyütür. Yeni ekibin görevine uygun erişimi tanımlayın ve devir bittikten sonra eski erişimleri gözden geçirin. Paylaşılan sırlar için uygun yenileme planı yapın; işlem sırasını belirlemeden çalışan entegrasyon anahtarını değiştirmek kesinti doğurabilir. Gizli bilgilerin düz e-posta içinde dağılmasını önleyin. Kimlerin hangi erişimi aldığı ve hangi tarihte kaldırılacağı kayıtlı olsun. Hesap sahipliği netleşirken hizmetin çalışması da korunmalıdır.

Verinin yapısını ve geri dönüş yolunu teslim edin

Veri tabanı şeması tek başına iş bilgisini anlatmaz. Müşteri durumları, silme davranışları, zaman alanları ve kritik ilişkiler için kısa bir veri sözlüğü hazırlayın. Bir kaydın arşivlenmesiyle silinmesi arasındaki farkı açıklayın. Dış sistemden gelen kimliklerin hangi tabloda tutulduğu da görünür olsun. Devralan ekip bir alanı gereksiz sanarak kaldırdığında raporlama veya eşleştirme bozulabilir. Veri açıklamaları bütün tabloları uzun uzun tekrar etmek yerine, yanlış yorumlandığında iş kaybı yaratabilecek noktaları aydınlatmalıdır.

Yedeğin nerede tutulduğunu söylemekle yetinmeyin; kontrollü bir geri yükleme deneyin. Kullanılan veri tabanı sürümünü, dosya eklerinin yerini ve geri yükleme sırasını yazın. Sonradan oluşan kayıtların nasıl ele alınacağı ayrıca düşünülmelidir. İşletmenin kabul ettiği veri kaybı ve toparlanma beklentisini varsaymayın. Testin sonucu, geçen süre ve karşılaşılan engeller teslim notuna girsin. Bir yedek dosyasının bulunmasıyla kullanılabilir bir kurtarma yolunun bulunması farklı şeylerdir; kararınızı gözlenen denemeye dayandırın.

Ekran dışında çalışan işleri görünür kılın

Örneğimizde günlük raporu hazırlayan zamanlanmış görev, kullanıcı arayüzünden bağımsızdır. Benzer şekilde kuyruk işleyicileri, dosya dönüştürme süreçleri ve dış bildirimler ayrı çalışabilir. Her iş için tetikleme biçimi, beklenen sonuç, hata durumunda sorumlu kişi ve güvenli tekrar yöntemi kaydedilmelidir. Aynı iş iki kere çalıştırıldığında mükerrer e-posta veya ödeme oluşuyor mu? Bu soruyu canlı müşteriler üzerinde denemeyin. Kontrollü ortamda davranışı görün ve işletmenin işlem düzenine uygun bir işletim talimatı hazırlayın.

Entegrasyonlarda yalnızca bağlantı adresini bilmek yetmez. Kullanılan yetki kapsamı, test hesabı, kota veya zaman aşımı davranışı ve başarısız kayıtların takibi açıklanmalıdır. Dış servis kesildiğinde kullanıcı ne görecek? Bekleyen işlem nerede tutulacak? Yeni ekip bu sorulara belge üzerinden cevap verebilmeli, ardından örnek bir akışla doğrulamalıdır. Entegrasyonun çalıştığına ilişkin eski bir ekran görüntüsü güncel bağlantıyı kanıtlamaz. Devir anındaki bağımlılıkları ve bilinen sınırlamaları tarihli bir kayıtla teslim edin.

Yayını, geri almayı ve alarmı birlikte deneyin

Devralacak ekip küçük ve düşük riskli bir değişikliği test ortamına yayınlasın. Hangi onayın gerektiğini, veri tabanı değişikliğinin nasıl uygulandığını ve başarının nasıl izlendiğini görsün. Geri alma planı yalnızca önceki dosyaları kopyalamaktan ibaret olmayabilir; veri yapısı değiştiğinde farklı adımlar gerekebilir. Yayın sırası ve durdurma koşulları yazılı olsun. Kimsenin canlı ortamda ilk kez bir komutun etkisini tahmin etmek zorunda kalmadığı bir devir hedefleyin. Denemenin boyutunu sistemin riskine göre seçin.

İzleme erişimini de aynı oturumda kontrol edin. Yeni ekibin hata kayıtlarını görebilmesi ve uygun uyarıyı alabilmesi gerekir. Uyarı eski geliştiriciye gitmeye devam ediyorsa görev kâğıt üzerinde devredilmiş olur. Servis çalışmıyor bildiriminin kime ulaşacağı, ilk müdahalenin ne olacağı ve işletmenin nasıl bilgilendirileceği açıklansın. Kişisel veri veya sır içeren logları gereksiz yere paylaşmayın. Gözlem araçları yalnızca bir gösterge panosu değil, sorunu anlamak ve doğru kişiye iletmek için kullanılabilir olmalıdır.

Kabulü bir toplantıdan çok bir çalışma oturumuna dönüştürün

Son oturumda yeni ekip kurulumu, temel müşteri akışını, test yayınını ve geri yüklemeyi kendisi göstersin. Eski ekip gerektiğinde açıklama yapsın; fakat her adımı onun gerçekleştirmesi öğrenme boşluklarını gizler. Cevapsız soruları sorumlu ve tarih bilgisiyle kaydedin. Kabul tutanağına bilinen hataları ve işletmenin kabul ettiği sınırlamaları ekleyin. Devir sonrasında kısa bir danışma dönemi gerekiyorsa süresini, erişim sınırını ve destek kanalını önceden belirleyin. Böylece geçişin hangi noktada tamamlandığı anlaşılır.

Yeni bir ürün geliştirirken teslim koşullarını sona bırakmamak daha kolaydır. BiKreatif’in özel yazılım projeleri kapsamında ihtiyaç analizi, geliştirme, test ve sürdürülebilir teslim birlikte ele alınabilir. Mevcut bir uygulamada ise önce küçük bir teknik durum incelemesiyle başlayın. Belgede eksik olan her satır aynı ağırlıkta değildir. Çalıştırmayı engelleyen bağımlılıklar, erişim sahipliği ve kurtarma belirsizliği önceliklidir. İyi bir teslim, gelecekte soru çıkmayacağını iddia etmez; soruyu cevaplayacak bilgiye ve yetkili kişiye ulaşmayı mümkün kılar.

Sık sorulan sorular

Kaynak kod teslimi bütün hakların devredildiğini gösterir mi?

Tek başına göstermez. Kodun teslim edilmesi, kullanım ve değiştirme haklarının kapsamını otomatik açıklamaz. Tarafların sözleşmesi ve kullanılan bileşenlerin lisansları ayrıca değerlendirilmelidir. Teslim envanterinde işletmeye ait geliştirmelerle dış bileşenleri ayırın. Hak kapsamını teknik ekipten varsaymak yerine yetkili taraflarla netleştirin; gerektiğinde konuya uygun uzman görüşü alın.

Eski geliştirici olmadan kurulum yapılamıyorsa devir tamam mı?

Bu durum önemli bir bilgi bağımlılığına işaret eder. Eksik adımı bulun, belgelendirin ve farklı bir yetkili kişinin yeniden denemesini sağlayın. Bazı işletim bilgileri erişim gerektirebilir; bunları herkese açık belgeye yazmanız gerekmez. Ama ilgili yeni ekip güvenli yoldan gerekli bilgiye ulaşabilmelidir. Kurulumun tekrarlanabilir olması somut bir kabul koşuludur.

Canlı müşteri verisini test ekibine vermeli miyiz?

Testin ihtiyacını belirlemeden canlı veriyi kopyalamayın. Çoğu iş akışı uygun örnek veya anonimleştirilmiş veriyle sınanabilir. Hassas veri gerekiyorsa erişim, saklama ve imha koşullarını ayrıca kararlaştırın. Devir kolaylığı, gereksiz veri paylaşımını haklı çıkarmaz. Kurulum belgesiyle müşteri veri dosyalarını ayrı erişim düzeninde tutun.

Devir sırasında bütün parolalar hemen değiştirilmeli mi?

Erişimleri gözden geçirin; fakat değişiklik sırasını çalışan hizmetleri düşünerek planlayın. Bir entegrasyon sırrı birden fazla görevde kullanılıyor olabilir. Yeni değerin güvenli tanımlanması, bağlantının denenmesi ve eski erişimin kaldırılması birlikte yürütülmelidir. Kimde hangi yetkinin kalacağı belirsiz bırakılmamalı, değişiklikler yetkili kişilerce kayıtlı biçimde tamamlanmalıdır.

Küçük bir projede de bu belgelerin tamamı gerekir mi?

Kapsam küçüldükçe belgenin uzunluğu azalabilir. Tek uygulama için kısa bir kurulum rehberi, hesap envanteri ve yayın notu yeterli bir başlangıç olabilir. Yine de çalışan sürümün bulunması, erişim sahipliği ve geri yükleme yolu açıklanmalıdır. Örneğin tek sunuculu bir talep uygulamasında da zamanlanmış raporun kim tarafından izleneceği ve hata durumunda kime haber verileceği belirtilmelidir. Belge sayısını değil, yeni ekibin gerekli işleri bağımsız ve güvenli yapabilmesini ölçün.