Microsoft D365 FO’nun yeni sürümlerinin mevcut hızlı görünümü ile test yapmak daha fazla zaman alabilir (yılda 10 kez). Bu durumda bazı kararlar vermenizde fayda var. Örneğin;
- Güncellemeleri atlayın ve örneğin yalnızca çift veya tek platform güncelleme numaralarını alın
- MS’i test etmeyin ve güvenin. Ancak lütfen MS’te sadece insan olduklarını ve insanların da hata yaptığını unutmayın.
- Daha kısa sürede daha fazla test yapılabilmesi için test ekibinizi artırın.
- Regression Suite Automation Tool kullanmaya başlayın.
Geçmişte 1. seçeneği seçiyorduk. Yine de her ay release çıkardık, ancak MS sürümüne ISV ile sürümler ve müşteri için özel çözümler dahil edilmedi.
Nasıl kullanabiliriz?
Müşterilerimizle RSAT hakkında konuşmaya başladığımızda, her zaman bütçe olmadığını söylüyorlar. Bu doğru değil, her zaman test maliyeti vardır. Sadece mevcut test maliyeti, dahili testler ve / veya üretim ortamlarında ortaya çıkan sorunlar şeklinde o müşterinin organizasyonunda gizlidir. Gördüğümüz şey; müşterilerin BT projeleri için bir bütçesi olduğu. Müşterinin / anahtar kullanıcının test ettiği saatler bu bütçenin parçası değildir.
Sonra başka bir nokta daha görüyoruz ki mevcut görev kayıtları (task recorder) çoğu zaman güncelliğini yitirmiştir (bkz. İş Süreci Modelleyiciniz (BPM) neden güncel olmalı? bloguna). RSAT kullanarak BPM kitaplığınızı otomatik olarak güncellemiş olursunuz.
RSAT, bir sağlama aracı gibi kullanarak daha da güçlü hale gelebilir. Aşağıda, veri hattı sürümünde kullandığımız bir örnek verilmiştir. İlk örnek, bir veri tabanını 1. katman (MS barındırılan veya müşteri tarafından barındırılan) üzerine geri yüklediğimiz zamandır.
Mevcut RSAT çözümünün bir bulut hizmeti olarak çalıştırmak yerine gerçek bir makineye kurulması gerekiyor. Bunu başarmak için, onu bulutta barındırılan bir Devbox’a kurduk ve maliyetleri yönetmek için otomatik kapatmayı açtık. Bu nedenle eğitimde söz konusu ortamı hem başlatan hem de durduran adımlar görüyorsunuz.
Devops’taki mevcut RSAT, yalnızca kurulu olduğu gerçek bir makinede çalışır. Bu yüzden onu bulutta barındırılan Devbox’a kurduk, Azure maliyetini düşük tutmak için bu sanal makineyi talep üzerine başlatıyoruz. RSAT provizyonunun parametrelerinde; veri tabanını yeni geri yüklediğimiz(restore) ortama işaret eden RSAT ayarları dosyasını seçiyoruz.
RSAT’ı kullandığımız görevler şunlardır:
• Kullanıcıları etkinleştirin
• Toplu işleri (Batch) başlatın
• Exchange ayarlarını güncelleyin
• Diğer tüm entegrasyon seçenekleri
Ancak RSAT, en son özelleştirilmiş müşteri kodunuzla yeni bir release yayınladığınızda da tekrar kullanılabilir. RSAT’ı bu şekilde kullanmamın nedeni; 1. Katman üzerinde yapılan testlerin dünyayı temsil etmemesi, paketi geliştirme alanında değil operasyonel alanda test etmek istiyorum.
Ve son durum, Microsoft’un güncellemeleri içindir. Yukarıdaki gibi benzerdir, RSAT görevini yalnızca MS versiyon aday ortamında çalıştırırsınız.
Şimdi iş durumu açıklandığına göre, yapı taşlarına kısaca bir göz atalım.
VM’yi başlatmak ve durdurmak için Azure CLI kullanıyoruz
Agent pools
Kullandığımız adımlar farklı agent pool’a ihtiyaç duyar. Ben her zaman sadece azure pipeline’ı kullanmayı tercih ediyorum. Ancak bunların bir sınırlaması var. Adımın sanal makinede bulunan programlara veya dosyalara ihtiyaç duyması halinde, sanal makinenin de bir agent pool’u olması gerekir. Aşağıdaki liste, bir müşteri uygulamasında ihtiyaç duyduğumuz agent pool’u göstermektedir:
Ayrıca, mevcut bir bulutta veya hatta yerel bir sanal makinede çalışan bir building pool’a ihtiyacınız olduğunu fark ettiğinizde, onu yine de kurabilirsiniz. Https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops ile ilgili bilgilere bakabilirsiniz.
Toparlamak gerekirse; RSAT’ın bir satış hikayesine ihtiyacı yoktur. Nasıl kullanılacağını bilirseniz, kendisini satmaya başlayacaktır.
Diğer DEVOPS ipuçları için https://kaya-consulting.com/category/lcs/ adresine bir göz atın.