Dynamics 365 Finance and Operations Branch Mantığı ve Lokal Klasörleri Azure DevOps projesine bağlama.
Bu yazıda Dynamics 365 Finance and Operations için versiyon kontrol kullanmak artık bir zorunluluk. Eski versiyonlarda da kullanma imkanı vardı ama çok iyi çalışmıyordu bu yüzden bu zamana kadar çalıştığım onlarca projenin sadece bir kaçında versiyon kontrol kullanmıştık. Tabi artık geliştirme ortamımızın Visual Studio olması bunu çok kolaylaştırıyor. Şimdi proje başlangıcında yapılması gereken temel birkaç ayarın nasıl yapılacağına ve Branch mantığına bakalım. Branch dal demektir ve kodunuzu yönetmeyi ve geliştiricilerin bağımsız çalışmasını sağlar. Birçok Branch stratejisi mevcut. Ben bu konuda bir uzman sayılmam bu yüzden mümkün olduğunca basit hallerini kullanmaya çalışıyorum. En çok kullanılan 3 yaklaşım şöyle. Main, Main ve Dev, Main, Dev ve Release. Bu 3 farklı yöntemi kullanabilirsiniz. Daha geniş bilgi için Branching strategies yazısını inceleyebilirsiniz. Ben genelde Dev ve Main yapısıyla ilerliyorum. Eğer proje küçük ve sizden başka geliştirme yapan birileri yoksa sadece Main ile de devam edebilirsiniz. Tek Branch olduğunda birleştirme işlemi gerekmiyor daha hızlı canlıya alım yapabiliyorsunuz ama belli şeyleri almak istemediğinizde tek Branch işinizi çözmediği için en azından Dev ile çalışmak gerekiyor. Şimdi ilk tanımlar nasıl yapılıyor ona bakalım.
LCS üzerinden Azure DevOps bağlantısının nasıl yapıldığını önceki yazılarımda anlattım. Bu bağlantıyı yaptığınızda Azure DevOps projenizin içinde aşağıdaki Trunk klasörü oluşacak. Bu yapıyı korumalısınız. Sadece ilk oluştuğunda Main de klasör olarak oluşuyor. Bunu Visual Studio içinden Branch’e çevirmelisiniz. Bende sıfır bir ortam olmadığı için resmini alamadım bu yüzden resimde Main Branch olarak var.
Resim-1
Bir klasörü Branch haline getirmek için Visual Studio içinden Source Control Explorer ekranını açıp klasöre sağ tıklayıp Branching and Merging -> Convert to Branch demelisiniz.
Resim-2
Şimdi bir önceki yazımda oluşturduğum modeli kullanarak Metadata ve Projects klasörlerini Azure DevOps projemizle ilişkilendirelim. Resimler sizi yanıltmasın. Sıfır bir ortamım olmadığı için resimleri önceden işlemleri yapılmış bir ortamdan çektim ama mantık aynı. Öncelikle bu projede sadece Main var. Eğer Dev ile çalışacaksanız bütün geliştirme ortamlarının Dev’e bağlanması gerekiyor. İşlem aynı. Source Control Explorer ekranını açıyoruz.
Resim-3
Sıfır ortamda Metadata ve Project altında klasör olmuyor. Onları dikkate almayın. Şimdi sol taraftaki Azure DevOps klasörlerini bizim sanal makinedeki klasörlerle ilişkilendirebiliriz. Not Mapped linkine tıklıyoruz.
Resim-4
K:\AosService\PackagesLocalDirectory ile mapliyoruz. Klasörü seçince otomatik Metadata ekliyor silmeyi unutmayın. Map ile işlemi tamamlıyoruz.
Resim-5
K:\VSProject klasörü oluşturuyorum. Bu şart değil ama yolu kısa bir yerde tutmanızda fayda var.
Resim-6
Aynı şekilde Projects klasörü üzerindeyken Not mapped linkine tıklıyoruz. K:\VSProjects ile ilişkilendiriyorum. Burada da direk Projects ekliyor dikkatli olun ben siliyorum. Map ile işlemi tamamlıyoruz.
Resim-7
Bu aşamada klasörlerimizi bağlamış olduk. Ancak hangi dosyalar versiyon kontrole dahil olacak belirlemedik. Önceki yazımda oluşturduğum Model ve projemi kullanarak bu bağlantıları oluşturalım. DmrWMS adında bir paketim vardı. Metadate’ya sağ tıklayarak Add Item to Folder diyoruz. Açılan pencerenden paketimizi buluyoruz.
Resim-8
Descriptor klasörüne girip paket ismiyle aynı olan xml dosyasını seçiyoruz. Bu dosya bizim paket ve model bilgilerini içeriyor.
Resim-9
Devam edip Item to add kısmında gördükten sonra Finish diyoruz.
Resim-10
Aslında kodlarımız model altında tutuluyor ama burayı proje üzerinden bağladığımız için başka bir ekleme yapmak gerekmiyor. Eğer varsayılan olarak eklenmezse Add Item to Folder diyerek projemizi de ekleyebiliriz. Versiyon kontrole sadece metadata ve kod eklemeniz gerekiyor bu aklınızdan çıkmasın. Baktığınızda DmrWMS model klasöründe tüm kodlarınızı görebilirsiniz. Burada model ve paket ismi aynı olduğu için kafanız karışmasın.
Resim-11
Şimdi projemize bir job ekleyelim ve onun versiyon kontrolde nasıl göründüğüne bakalım.
Resim-12
Projemi oluştururken versiyon kontrole ekle diye işaretlemiştim. Sonradan da ekleyebilirim. Bu yüzden yeni bir nesne oluşturunca otomatik olarak model klasörümde oluştu.
Resim-13
Panding Changes kısmında bekleyen Check In lerimi görebilirim. 3 dosya var. Olması gerekenlerde bunlar. Proje dosyam Paket dosyam ve Job. Check In yapalım ve Azure DevOps üzerinden geliştirmemizi görelim.
Resim-14
Bu aşamaya kadar geldiyseniz geliştirme yapmaya hazırsınız demektir. Aynı yapıyı Azure DevOps üzerinden de gördük. Artık Build ve sonrasında test ve canlıya alım işlemlerini yapabiliriz.
Resim-15
Bu yazıda yeni bir proje için gerekli olan Azure DevOps ile Devbox makinenin ilk klasör ilişkilendirmesi ve yeni oluşturduğumuz model, paket ve projenin nasıl bağlanacağını anlatmaya çalıştım. Bu konu daha çok su kaldırır ama en azından bir giriş yapmak istedim. İlerde daha ayrıntılı konularına değineceğim. Örneğin Branch mantığı, tek bir doğru yok herkesin farklı tecrübeleri var. Ekibe ve projeye göre karar vermek gerektiğinde de değişiklik yapmak lazım. Burada bir tavsiye Dynamics 365 tecrübesi olamayan ama Azure DevOps uzmanı olan birçok kişi var onlardan destek alınabilir ama her zaman Dynamics 365 in kendine has özelliklerini anlatmakta fayda var. Daha doğru bir çözüm üretmiş olursunuz.
Selamlar.
www.fatihdemirci.net
TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, Project onboarding, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apss, Power Virtual Agents, Dynamics 365 nedir, Dynamics 365 ERP, Dynamics 365 CRM
