1. Ana Sayfa
  2. Dynamics 365
  3. Dynamics 365 Finance and Operations Branch Mantığı ve Lokal Klasörleri Azure DevOps projesine bağlama

Dynamics 365 Finance and Operations Branch Mantığı ve Lokal Klasörleri Azure DevOps projesine bağlama

Image00

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.

üzerinden DevOps bağlantısının nasıl yapıldığını önceki yazılarımda anlattım. Bu bağlantıyı yaptığınızda 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.

Bu konuyla ilgili sorularınızı https://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar:
www.mshowto.org

TAGs: , LCS, Azure, Azure DevOps, Project onboarding, , MsDyn365FO, , MsDyn365, , , , , , Dynamics 365 ERP, Dynamics 365 CRM

Yorum Yap

Yazar Hakkında

2005 yılında Kocaeli Üniversitesi Bilgisayar Mühendisliğinden mezun oldum. Okulda ve ilk iş tecrübelerimde farklı yazılım dilleri kullandım. 2007 yılında Akşam gazetesinde işe başladım ve Microsoft Dynamics 365 (eski adıyla Axapta) ile orda tanıştım. Hiç duymadığım bir dil olan X++ kullanılıyordu. Kısa sürede adapta oldum ve kariyerimi bu alanda şekillendirdim. Bir kaç iş değişikliğinde sonra kendi firmamı kurdum. Şu anda DMR de yönetici ortak ve Çözüm mimarı olarak çalışmaktayım. 2010 yılında MCT oldum. Birçok faklı ortamda eğitimler verdim. Bloğum ve Youtube kanalımda tecrübelerimi paylaşmaktayım.

Yorum Yap