Değişiklik hep aynı cümleyle başlar: “Filtreye bir statü daha ekleyelim, ufak bir şey.” Gerçekten ufaktır. Sorun tek bir değişiklikte değil, üçüncü ayda o cümlenin kaç kez kurulduğunu kimsenin bilmemesindedir.
Klasik değişiklik yönetimi kodun etrafına kurulmuştur: geliştirme yapılır, transport isteğiyle taşınır, kalite sisteminde test edilir. Oysa düşük kodlu akışlarda üretim davranışını belirleyen şey çoğu zaman bir tanımdır — bir iDataView rapor tanımı, bir servis, bir aktarım projesi. Tanım kod kadar etkilidir; ama kod kadar disiplinle yönetilmez.
Birikim sessiz ilerler. İlk ay iki tanım değişir, ikinci ay beş, altıncı ayda kimse hangi sürümün canlıda olduğunu hatırlamaz. Eşik genellikle bir denetimde ya da bir hata incelemesinde görünür: birinin “bu filtre ne zaman değişti?” diye sorduğu anda.
Tanım sürümü, devralma ve geri alma
Bu soruyu cevaplayan mekanizmalar ürünün içinde duruyor. iDataView tarafında pasif ve aktif sürümler ayrı yönetilir: aktif sürümden devralabilir, farklı kaydedebilir ve son kaydı geri alabilirsiniz. BI görünüm tasarımı dosya olarak dışa ve içe aktarılabilir; hedef sistemde kaynak eşlemesi yapılır. Geliştirme, kalite ve canlı sistem ilişkileri tanımlanabilir, sistem verileri kontrollü biçimde başka bir sisteme kopyalanabilir.
Transport isteği neyi taşır, neyi taşımaz?
Üretilen ABAP kodu ve DDIC tabloları SAP transport isteğiyle taşınır; isteğin değiştirilebilir durumda olup olmadığı kontrol edilir. Bu SAP’nin kendi taşıma mekanizmasıdır ve kapsamı SAP nesneleridir. Ürün tarafındaki tanımlar aynı istekle yolculuk etmez: BI görünümü dosya olarak dışa ve içe aktarılır, sistem verileri tanımlı sistem ilişkileri üzerinden kopyalanır. Bu ayrımı atlamak, “transport geçti, her şey taşındı” varsayımını üretir.
Değişiklik denetim kaydı ne söylüyor?
Kayıt var: bir tanımın ne zaman ve kim tarafından değiştirildiği görüntülenebilir. Söylemediği şey nedendir. Üç ay sonra kararı savunmak zorunda kalmayan ekip, o tek satırlık gerekçeyi zamanında yazmış olan ekiptir.
Mekanizmalar tek başına süreç kurmaz. Pratikte işleyen düzen üç kurala iniyor:
- Canlıda doğrudan tanım değiştirmeyin. Bir aktarım projesinin filtresini canlıda değiştirmek, kod değiştirmekle aynı risktedir; tek farkı geri almanın daha kolay görünmesidir.
- Gerekçeyi kaydın yanına yazın. Talebi kimin açtığı, hangi kapsam için değiştirildiği ve neyin test edildiği tek cümleye sığar.
- Test kapsamını tanımın türüne göre seçin. Rapor tanımında çıktı kontrolü yeterli olabilir; SAP’ye yazan bir projede küçük veri kümesiyle çalışma ve hedef tablo kontrolü gerekir.
DDIC tablosu ve ona bağlı tanımlar
İki nokta özellikle dikkat ister. Birincisi silme ve yeniden oluşturma akışı: tabloda veri olup olmadığı kontrol edilir, ama bu kontrol bir onay süreci değildir ve uyarıyı okuyan kişi ile o verinin sahibi genellikle aynı kişi olmaz.
İkincisi tanımların birbirine bağlı olması. Aktif bir iDataView aynı zamanda bir API servisinin ya da SQL aktarım projesinin kaynağı olabilir; rapor için yapılan bir alan değişikliği, kimse fark etmeden bir entegrasyon sözleşmesini bozabilir.
Bu yüzden değişiklik öncesi en kullanışlı soru teknik değil, envanter sorusudur: bu tanımı başka hangi akış kullanıyor? Önümüzdeki hafta canlıdaki tanımlardan üçünü seçin ve son altı ayda kaç kez değiştiklerini çıkarın. Sayı beklediğinizden yüksekse gözden geçirilmesi gereken şey geliştirme süreciniz değil, tanım süreciniz olabilir; o gözden geçirmeye mevcut tanım envanterinizle birlikte başlayabiliriz.