Versiyon geçişine kendi kodumuzdan başlamak

Selamlar, bu yazıda Dynamics 365 sürüm geçişlerinde yapay zekâdan nasıl faydalanabileceğimizi bir örnek üzerinden anlatacağım. Yeni versiyon geldiğinde kendi geliştirmelerimiz etkileniyor mu, nerede sorun çıkabilir, hangi işlemleri test etmeliyiz? Bu sorulara kod üzerinden cevap aramak istedim.

Benim geliştirme makinemde iki farklı build’e ait Microsoft paketleri bulunuyor. Her birinde 170’ten fazla paket ve on binlerce nesne var. Hepsine bakmak yerine önce kendi modelimizin standart kodla bağlantılarını çıkarıp ilgili nesneleri karşılaştırdım.

Bu çalışma için Claude Code kullandım. Karşılaştırma betiğini hazırlamasını, değişen kodları bizim geliştirmemizle birlikte incelemesini ve etkisini açıklamasını istedim. Bu modelde kontrol birkaç dakika sürdü.

Burada Finance, Supply Chain Management, Commerce ve Human Resources’ın ortak X++ ve metadata altyapısındaki geliştirmeleri ele alıyorum. Paylaştığım sonuçlar kod incelemesine ait. Yeni sürüme karşı derleme ve uygulama testlerini henüz yapmadım.

Karşılaştırdığım iki build

UDE ile çalıştığım makinede aşağıdaki iki build’in paketleri zaten vardı. Karşılaştırmayı bu klasörler üzerinden yaptım:

%LOCALAPPDATA%\Microsoft\Dynamics365\10.0.2527.116\PackagesLocalDirectory   (mevcut)
%LOCALAPPDATA%\Microsoft\Dynamics365\10.0.2645.99\PackagesLocalDirectory    (yeni)

Kendi modellerim ayrı bir metadata klasöründe duruyor. Örnek olarak icra süreçleri için geliştirdiğim test modelini kullandım. İhtiyacım olan paketler makinede olduğu için ek bir araç kurmama veya paket indirmeme gerek kalmadı.

Önce kendi modelimize bakalım

İlk olarak Claude Code’dan modelimizin Microsoft koduna bağlandığı yerleri listelemesini istedim. CoC ile hangi metotları kullanıyoruz, hangi tablo ve formları genişletiyoruz, hangi standart sınıfları çağırıyoruz? Bunlara yazı boyunca temas noktası diyeceğim. Liste aşağıdaki gibi çıktı:

Tablo 1. Modelimizin Microsoft koduna bağlandığı noktalar

Böylece bakacağımız Microsoft nesnesi sayısı 14’e indi. Paket listelerini de karşılaştırdık. Yeni build’de beş paket eklenmiş, bir paket kaldırılmıştı. Kaldırılan paket bizim modelin doğrudan referanslarında yoktu. Bu tarafta ilk bakışta bir sorun görünmüyordu; bağımlılıkların derleme tarafını ayrıca kontrol edeceğim.

Bu nesnelerde ne değişmiş

Sonra bu 14 nesnenin XML dosyalarını iki build arasında karşılaştırdık. Tablo ve sınıflarda metotlara, formlarda kontrollere baktık. Sonuç şöyleydi:

Tablo 2. Karşılaştırma sonucu

Burada ilk dikkatimi çeken LedgerJournalCheckPost oldu. Bizim icra kaydı oluşturma servisimiz günlüğü bu sınıfla deftere naklediyor. Sınıfın nakil metotları değişince önce buraya bakmak istedim.

Değişen kod bizim işlemimizde çalışıyor mu

Sınıf değişmiş, peki bizim kullandığımız akışta ne oluyor? Bunun için farkları kendi kodumuzla birlikte incelemesini istedim. Hangi koşul eklenmiş, bu koşula bizim işlemimiz giriyor mu, asıl bakmak istediğim buydu.

LedgerJournalCheckPost içindeki değişiklik

Doğrudan çağırdığımız newLedgerJournalTable ve processOperation metotları aynıydı. Burada bırakmayıp devamındaki nakil akışına da baktık. postJournalLines ve checkJournalStatus metotlarına eklenen kontrollerin ilgili kısmı şöyle:

if (ledgerJournalTrans.AccountType == LedgerJournalACType::Vend
&& LedgerJournalTrans::isVendorInvoice(ledgerJournalTrans))
{
…
if (ledgerJournalTableForValidation.JournalType
== LedgerJournalType::VendInvoiceRegister)
{
allOK = allOK
&& this.validateEstablishment(…)
&& this.validateVendorShipFromAddress(…)
&& this.validateRegistrationIds(…);
}
}

Bu kontroller satıcı faturası kayıt günlüklerindeki satıcı satırları için çalışıyor. Bizim icra günlüğümüz ise müşteri ve ana hesap satırlarından oluşan bir genel günlük. Dolayısıyla bizim işlemimiz bu koşula girmiyor. postJournal metodundaki diğer değişiklik de Hindistan’a özgü vergi koduyla ilgiliydi.

İncelediğimiz bu değişiklikler için icra kodunda bir düzeltme ihtiyacı görmedik. Yalnızca dosyaları karşılaştırsaydık elimizde “nakil sınıfı değişmiş” bilgisi olacaktı. Kodun hangi durumda çalıştığına bakınca bizim işlemimizle ilişkisini anlayabildik.

Diğer nesnelerdeki durum

CustTable tablosunda FiscalCode alanındaki İtalya’ya özgü bir özellik bayrağı kaldırılmıştı. Bizim CoC ile sarmaladığımız validateWrite ve kullandığımız find, name metotları aynıydı. Baktığımız yerlerde kodumuzu etkileyen bir fark çıkmadı.

CustParameters tablosuna faturayla ilgili iki parametre alanı, forma da dört kontrol eklenmişti. Biz icra alanlarını General sekmesine ekliyoruz. Bağlandığımız GeneralFastTab ve GeneralTabPage kontrolleri yerindeydi. Yeni kontroller başka sekmelerde olduğu için bizim yerleşimle çakışmıyordu.

OrganizationAdministration menüsüne de yeni bir öğe eklenmişti. Bu ekleme bizim menü extension’ının yerleşimini etkilemiyordu.

Sonuç ne oldu ve nereleri test edeceğim

Tablo 3. Etki değerlendirmesi

14 nesnenin dokuzu aynı kalmış, beşi değişmişti. Değişenlerde de incelediğimiz icra senaryosu için kod düzeltmesi gerektiren bir durum bulamadık. Şimdi bu değerlendirmeyi yeni sürümde doğrulamak gerekiyor. Önce şu işlemleri test edeceğim:

İcra kaydı oluşturup günlüğü deftere nakletmek. Nakil sınıfında değişiklik olduğu için müşteri ve ana hesap satırlarıyla işlemin tamamlandığını kontrol edeceğim.

Yeni müşteri oluşturmak ve mevcut müşteriyi düzenlemek. CustTable üzerindeki özel doğrulamanın, kurala uyan ve uymayan veride beklediğimiz gibi çalışmasına bakacağım.

Alacak hesapları parametrelerindeki icra alanlarını kontrol etmek. Alanlar doğru yerde mi, değerler değiştirilebiliyor mu, kaydettikten sonra formu yeniden açınca aynı değerler geliyor mu?

Bu listeyle hangi teste neden öncelik verdiğimiz belli oluyor. Projenin kritik regresyon testleri de devam edecek. Burada yaptığımız kontrol, kendi geliştirmemizle ilgili testlere nereden başlayacağımızı gösteriyor.

Sonuç ve sonraki adım

Bu çalışma küçük bir model üzerinde yaptığım bir denemeydi. İncelediğimiz değişikliklerde kendi senaryomuz için bir düzeltme ihtiyacı çıkmadı. Gerçek bir projede ise yüzlerce nesneyi etkileyen değişiklikle ve bunların özel geliştirmelerimizle çakıştığı durumlarla karşılaşabiliriz. Böyle bir kapsamda farkları tek tek okuyup etkilerini değerlendirmek çok daha fazla zaman alacaktır.

Bence YZ’nin burada sağlayacağı fayda da bu. Değişiklikleri kendi kodumuzla birlikte inceleyerek olası sorunları daha erken görebilir, düzeltme ve test çalışmalarına nereden başlayacağımızı belirleyebiliriz. Tabii standart süreçler, parametreler, veri ve Feature management değişikliklerini de ayrıca değerlendirmemiz gerekiyor.

Benim bir sonraki adımım, modeli hedef build’e karşı derlemek ve belirlediğimiz testleri yeni sürümdeki sandbox ortamında çalıştırmak olacak. Bu denemeyi daha geniş bir modelde de tekrarlayıp çıkan sorunları ve sonuçları paylaşmak istiyorum.

Selamlar,
Fatih Demirci

Denemek isteyenler için kullandığım komutlar

1 Kendi modelimizin temas noktaları

List every place where our model DMRAITests touches Microsoft code: Chain of Command classes and the methods they wrap, table, form, menu and security extensions, data entities, and the Microsoft classes and methods our code calls. Show the result as a table.

2 Paketleri karşılaştırma

Compare the package lists of the two builds under %LOCALAPPDATA%\Microsoft\Dynamics365 (10.0.2527.116 and 10.0.2645.99). Which packages were added or removed, and does our model reference any of them?

3 Temas noktalarındaki farklar

For each Microsoft object in the touchpoint list, compare its XML between the two builds. Report which objects are identical and which changed. For changed classes and tables, list added, removed and changed methods and fields; for forms, list added and removed controls. Tell me explicitly whether the methods we call or wrap changed.

4 Değişikliğin kendi kodumuza etkisi

For every changed object, read the diff together with our code and decide whether it actually affects us. Show the relevant Microsoft code and explain under which conditions the new logic runs.

5 Form bağlantı noktaları

Check that every control our form extensions attach to (parent or previous sibling) still exists in the new build.

6 Sonuç ve test listesi

Summarize the result as three groups: unchanged, changed but no direct impact identified in the reviewed scenario, changed with impact. Then give a short, prioritized test list for this upgrade and say why each test is on it.

7 Yeni build’e karşı derleme

Bu son komutu henüz çalıştırmadım. Derleme adımında mevcut ve hedef build’in sonuçlarını karşılaştırmak için kullanacağım.

Compile DMRAITests with xppc against the 10.0.2645.99 packages and list any errors or warnings that do not appear when compiling against 10.0.2527.116.