Ajans teklif uygulamanızın kaynak kodunu gönderdi. Ertesi sabah yeni geliştirici bir indirim hatasını giderecek. Hangi sürümü açacak, paketi hangi hesaptan indirecek, yaptığı değişikliği müşteriye göstermeden nerede deneyecek? Toplantıda klavyeyi işi devralacak geliştiriciye bırakın.
Kaynak kodu, geliştiricinin okuyup değiştirebildiği proje dosyalarıdır. Birlikte teslim edilecek varlıkları başlangıçtaki yazılım kapsamı ve kabul koşullarında arayın. Örneğin şirkete özel sipariş modülünün kodu, lisansla kullanılan rapor bileşeni ve aylık e-posta hizmeti farklı kayıtlardır. Hazır ürün ile özel geliştirmeyi ayırdıktan sonra her birinin nasıl kullanılacağını ve bir sonraki ekibin nereye başvuracağını ayrı yazın.
1. Depodaki Kodu Yayındaki Sürümle Eşleştirin
Teslimi yapan kişiden son başarılı yayının kaydını açmasını isteyin. Hangi uygulamanın hangi ortama, hangi koddan çıktığını birlikte okuyun. Git kullanan ekipte aradığınız bilgi commit kimliği, yani kaydedilmiş değişiklik kümesini gösteren değerdir. Sürüm etiketi insanların tanıyacağı bir isim verir. Etiketin işaret ettiği tam kimliği devir kaydına ekleyin. Teslimden iki hafta sonra ana dal ilerlese bile doğru noktayı bulabilirsiniz.
Basit bir fiyat hesabıyla yerel bir deneme yaptık. Örnek uygulamanın v1.0 etiketinde 100 birim üzerinden yüzde 10 indirim uygulanıyordu. Ana dala yüzde 20 indirim ekledik. Depoyu ayrı bir klasöre klonlayıp uygulamayı çalıştırdığımızda sonuç 80 çıktı. Aynı kopyada teslim için ayırdığımız 1fd4ffa değişikliğine geçtiğimizde sonuç 90 oldu. İki sürüm de açılıyordu. Hangisinin doğru olduğu, iş sahibinin kabul ettiği indirim kuralına bağlıydı.
Ekibe ZIP verildiyse arşivin nasıl üretildiğini sorun. GitHub’ın standart kaynak kodu indirmesi seçilen sürümdeki dosyaları içerir. Değişiklik geçmişini incelemek için depoya erişim gerekir. Büyük dosyalar ayrı depolanıyorsa örnek bir varlığı açın. Özel paket, alt depo veya kurulum sırasında indirilen bir bileşen varsa yeni hesabın oraya da erişebildiğini doğrulayın.
2. Hesapları Kimin Yönetebildiğini Deneyin
Şirketten yetkili biri kendi hesabıyla giriş yapsın. Depoda bir ekip üyesini davet edebiliyor mu? Bulut hesabında fatura ve kurtarma bildirimleri doğru kişiye gidiyor mu? Yalnız uygulama paneline giriş yapabilen bir yönetici, barındırma hesabını kurtaramayabilir. Her varlık için idari yetkiyi, günlük işi yapacak kişiyi ve acil durumda ulaşılacak ikinci kişiyi yazın.
| Varlık | Kontrolü yapacak kişi | Kayda girecek kanıt |
|---|---|---|
| Kaynak deposu | Şirketin yetkili hesap yöneticisi | Alıcı kuruluş altında doğru depoyu ve üye rollerini gördü. |
| Paket ve yayın ortamı | Devralan geliştirici | Özel paketi okuyup seçilen sürümü deneme ortamına kurdu. |
| Bildirim hizmeti | Entegrasyonu yöneten ekip üyesi | Deneme anahtarıyla örnek mesajın test kutusuna ulaştığını gördü. |
| Kurtarma erişimi | İşletmenin belirlediği yedek sorumlu | Kendi hesabıyla yetkisini ve ulaşacağı destek kanalını doğruladı. |
Depoyu başka bir kuruluşa taşıyorsanız aktarım sonrasını da inceleyin. GitHub’ın depo devri açıklamasına göre erişimi olan kişiler ve bağlı dağıtım anahtarları aktarım sonrasında kalabilir. GitLab’ın dosyayla proje dışa aktarma işleminde ise yayın değişkenleri, webhook’lar ve paket kayıt deposundaki imajlar dışarıda kalır. Kullandığınız platformda uygulanan yöntemi yazın. Ekrandaki “tamamlandı” bildirimi hangi işlemi doğruluyor, ekip oradan anlayabilsin.
Parolayı teslim tutanağına yazmayın. Tutanakta kasadaki kaydın adı, yetkili kişi ve son kontrol tarihi yer alabilir. Üretim anahtarı kullanan zamanlanmış işler varsa önce hangi işlerin o anahtara bağlı olduğunu çıkarın. Yeni kimlik bilgisiyle çalıştıklarını doğruladıktan sonra eskisini iptal edin. OWASP’ın gizli bilgi yönetimi rehberinde anahtar yenileme yöntemlerini inceleyebilirsiniz.
3. Kurulumu Devralan Ekibe Yaptırın
Klavyeyi yeni geliştiriciye bırakın. Temiz bir deneme ortamı, kurulacak sürüm, gerekli çalışma zamanı, bağımlılık listesi ve örnek yapılandırma önünde olsun. Gerçek müşteri verileri yerine temsili kayıtlar kullanın. E-posta ve ödeme çıkışlarını test hedefine yöneltin. Önceki geliştirici kendi bilgisayarından dosya göndermek zorunda kalırsa durun. Dosyanın adı, güvenli kaynağı ve ona ihtiyaç duyulan adım kurulum notuna girmeli.
İlk ekrana bakıp toplantıyı kapatmak kolaydır. Oysa satış ekibi teklifi kaydederken arka plandaki PDF üretimi özel bir pakete, bildirimi de başka bir hesaba bağlı olabilir. Teklif oluşturun, indirimli tutarı okuyun ve test adresine gönderimi izleyin. Gönderim başarısızsa hangi kayıttan nedenini bulabildiğinizi gösterin. Entegrasyonu planlarken belirlenen veri ve hata sorumluları, başarısız adımın kime gideceğini netleştirir.
Bir komutu bilmek, çalıştırmak için gereken erişimi sağlamaz. Örneğin npm kullanan projelerde temiz bağımlılık kurulumu kilit dosyasıyla paket tanımı uyuşmadığında hata verir. Deneme sırasında eski bilgisayarın önbelleği devredeyse eksik özel paket gözden kaçabilir. İşe yeni katılan birinin sahip olacağı izinlerle tekrar deneyip sonucu yazın.
4. Açık İşlerle Birlikte Teslimi Kayda Geçirin
“Kurulum yapıldı” cümlesini aylar sonra okuyan kişi hangi sürümün ve hangi işlevin sınandığını bilemez. Örneğin şöyle yazabilirsiniz: “Deneme ortamında v1.0 ile oluşturulan 100 birimlik teklif 90 birim olarak kaydedildi. PDF açıldı. Test posta kutusuna gönderim, servis yetkisi bekliyor.” İlk iki sonuç kapanabilir. Posta erişimini sağlayacak kişiyi, tekrar deneme tarihini ve kontrolü kimin yapacağını son satıra ekleyin.
Ortamı yeniden kurmaya yarayan kısa bir belge bırakın. Başlangıç komutu, gerekli ayarların adları, deneme verisinin yeri, son başarılı yayın ve geri dönüş adımları aynı sürümden ulaşılabilir olsun. Veri tabanı şeması değiştiyse yalnız uygulamayı önceki sürüme almak yetmeyebilir. Dönüşün hangi koşullarda mümkün olduğunu ve hangi adımın gerçekten denendiğini sorumlusuyla birlikte kaydedin.
Son soruyu işi devralan kişiye sorun. “Yarın teklif PDF’i oluşmazsa ilk hangi kaydı açarsın?” Kendi hesabıyla kaydı bulabiliyor, hatanın sahibine ulaşabiliyor ve hangi sürümün çalıştığını söyleyebiliyorsa teslim belgesi günlük işte karşılığını bulmuş demektir.
İlk teslim ile sonraki destek döneminin sınırını yazılım teklifindeki test ve destek kalemleriyle karşılaştırın. Kurum sitesi de uygulamaya bağlıysa alan adı yenilemesi, site güncellemeleri ve form takibini web sitesi bakım görevlerine dağıtabilirsiniz. Tek seferlik devir kaydının yanında, ertesi ay işi kimin sürdüreceği de belli olsun.
Yazılımınızı Devralacak Ekiple Teslimi Planlayın
Devir toplantısına hazırlanırken bize kritik bir kullanıcı işlemini ve elinizdeki teslim listesini anlatabilirsiniz. Metazen’in yazılım ekibi ile hangi sürümün kurulacağını, hangi rolün gerekeceğini ve kabul sırasında hangi sonucu görmek istediğinizi konuşabiliriz. Mevcut uygulamanızı devralma veya geliştirmeyi sürdürme ihtiyacınız için özel yazılım hizmetimizin kapsamını inceleyebilirsiniz.
