Çözümlerinizi düzenleme

Çözümler oluşturmadan önce, ortam stratejinizi ve çözüm stratejinizi önceden planlamak için biraz zaman ayırabilirsiniz. Aşağıdaki özellikleri göz önünde bulundurun:

Görünüş	Değerlendirme
Uygulama kapsamı	Uygulamanız Sales, Customer Service, Field Service, Finance gibi birden çok uygulamaya mı yayılsın?
Yayın sıklığı	Güncelleştirmeleri üretime ne sıklıkta dağıtmayı planlıyorsunuz? Teslim metodolojiniz sprint döngüleri gibi çevik uygulamaları temel alır mı?
Üretim desteği	Yeni özellikleri erken kullanıma sunmadan üretimde acil düzeltmeleri nasıl karşılarsınız?
Çözüm mimarisi	Kaç çözümü yönetiyorsunuz? Bu çözümler bileşenleri paylaşıyor mu yoksa birbirine mi bağlı?
Ortam planlama	Geliştirme yaşam döngünüzü desteklemek için kaç Microsoft Dataverse ortamına ihtiyacınız var? Geliştirme, test ve üretim için ayrı ortamlara mı ihtiyacınız var? Geliştiriciler paylaşılan bir ortamda işbirliği içinde mi çalışıyor yoksa bağımsız olarak çalışmak için yalıtılmış ortamlar mı gerekiyor?

Aşağıdaki bölümlerde, en basitten en karmaşıka kadar düzenlenmiş üç strateji özetlenmektedir ve ilgili avantaj ve dezavantajları vurgulanmıştır.

Tek çözüm stratejisi

Tüm özelleştirmeler, geliştirme sırasında yönetilmeyen tek bir çözüm halinde gruplandırılır ve daha sonra dağıtım için tek bir yönetilen çözüm olarak dışarı aktarılır.

Aşağıdakiler için önerilir:

• Küçük-orta ölçekli uygulamalar
• Gelecekteki modülerleştirmenin olası olmadığı senaryolar

Avantaj	Dezavantaj
Basitleştirilmiş ortam kurulumu ve yönetimi.	Gerekirse daha sonra ölçeklendirmek veya modüler hale getirmek için daha fazla çaba gerektirir.
Basitleştirilmiş dağıtım. Yönetilecek yalnızca tek bir çözümle, ortamlar arasında dışa ve içe aktarma işlemleri kolay ve daha az hata riski taşır.	Çok sayıda özelleştirme içeren tek bir çözüm, dağıtım sürelerinin daha uzun olmasına neden olabilir. Çözüm boyutunu küçültmek için tablo segmentasyonu kullanın. İçeri aktarma sürelerini azaltmak için performans önerileri'ne gidin.
Değişiklikleri bulmak, denetlemek ve yönetmek daha kolay.	Aynı geliştirme ortamında birden çok geliştirici çalıştığında, birbirlerinin değişikliklerinin üzerine yazma riskiyle karşı karşıyadırlar. Bu risk, kaynak kodu sürüm oluşturma uygulanarak, dallanma stratejisi benimsenerek ve her dal için ayrılmış bir geliştirme ortamı kullanılarak azaltılabilir. Kaynak kodu sürüm oluşturma ve dallanma stratejisi değişiklik izleme, işbirliği desteği ve çakışma çözme mekanizmaları sağlar. Daha fazla bilgi: Git dallanma stratejisini benimseme.

Not

Microsoft Power Platform'daki son geliştirmeler, yükseltme seçeneğini kullananlar da dahil olmak üzere yönetilen çözümler için içeri aktarma sürelerini azaltmıştı. Bu iyileştirmeler, bileşen bağımlılıklarının daha iyi işlenmesini ve değişmeyen bileşenler için ek yükün azaltılmasını içerir. Bu geliştirmelerden nasıl yararlanacağınızı öğrenmek için performans önerileri bölümüne gidin.

Aynı geliştirme ortamında birden çok çözüm

Birden çok yönetilmeyen çözüm, genellikle ilgisiz özelliklere veya modüllere ayrılmış tek bir geliştirme ortamında tutulur.

Aşağıdakiler için önerilir:

• Bileşenleri paylaşmayen ayrı ve bağımsız işlevsel alanlara sahip küçük orta ölçekli uygulamalar.

Avantaj	Dezavantaj
Basitleştirilmiş ortam kurulumu ve yönetimi.	Aynı geliştirme ortamında birden çok yönetilmeyen çözümün korunması bağımlılık çakışması olasılığını artırır. Örneğin, Çözüm A'nın B Çözümüne bağlı olduğu için içeri aktarılamadığı, Çözüm B'nin ise Çözüm A'ya bağlı olduğu için içeri aktarılamadığı bir durumla karşılaşabilirsiniz.
İşlevsel alanlar birbirinden bağımsız olarak dağıtılabilir.	Aynı geliştirme ortamında çalışan birden fazla geliştirici, birbirlerinin yaptığı değişikliklerin üzerine yazabilir. Yönetilmeyen bir çözümde çalışmak yalıtım sağlamaz. Her değişiklik, hangi çözümün düzenlendiğine bakılmaksızın doğrudan ortama uygulanır.

Not

Aynı geliştirme ortamında birden çok çözüm varsa, yönetilen çözümleri hedef ortamınıza aktardıktan sonra genellikle katmanlar oluşturursunuz. Daha fazla bilgi: Çözüm katmanları ve birleştirme davranışı

Şu şekilde olmanız önemlidir:

• Aynı yönetilmeyen bileşeni birden fazla çözüme eklemeyin.
• Tüm tablolarınızı içeren tek bir çözüme sahip olun. İkisinin de tablo içerdiği iki farklı çözüm olmamalı. Bunun nedeni, tablolar arasında, bir çapraz çözüm bağımlılığı oluşturan ve sonraki bir zamanda hedef ortamdaki sorunları çözümü yükseltmeye veya silmeye neden olan tabloları arasında sıkça görülen risklerin olmasıdır.
• Yalnızca bir çözüm yayımcısı kullanın. Çözüm yayımcısı yönetilen çözümün bileşenlerine sahip olur ve ilişkisi daha sonra değiştirilemez. Örneğin, özel bir tablo Publisher X ile Çözüm A aracılığıyla yönetiliyor olarak içeri aktarılırsa, bu tabloyu daha sonra Publisher Y ile Çözüm B'ye taşıyamazsınız. Tek seçenek tabloyu silmek, tabloyu hedef sistemden kaldırmak için Çözüm A'yı yükseltmek, ardından Tabloyu Publisher Y ile Çözüm B'de yeniden oluşturmak ve B Çözümünü içeri aktarmaktır. Bu işlem, önceden geçirilmediği sürece özel tabloda depolanan tüm verilerin kaybolmasına neden olur.
• Çözümler arasında bağımlılık oluşturmaktan kaçının. Bağımlılıklar bir dağıtım sırasını zorunlu kılar ve sorunlara neden olabilir. Örneğin, tablolar için bir çözümünüz ve bulut akışları için başka bir çözümünüz varsa ve bir akış özel sütuna dayalıysa, sütun mevcut olduğundan geliştirme aşamasında çalışır. Ancak, yalnızca bulut akışı çözümü hedef ortama aktarılırsa, içeri aktarma işlemi özel sütundaki bağımlılığı tanımayabilir. Sonuç olarak akış çözümü başarıyla yüklenir, ancak akışın kendisi çalışmaz. Daha fazla bilgi: Birden çok çözüm tarafından oluşturulan bağımlılık örnekleri

Birden çok çözüm tarafından oluşturulan bağımlılık örnekleri

• Uygulama şeritleri. Birden çok çözüm uygulama şeridini veya aynı uygulamanın site haritasını değiştirdiğinde.
• Eklentiler veya bulut akışları. Eklenti veya akış özel bir sütunda tetiklendiğinde veya özel bir tabloyu güncelleştirdiğinde, nesne bu özel tablolara bağlıdır.
• Güvenlik rolleri. Özel tablolar mevcut olduğunda, güvenlik rolleri genellikle kullanıcı erişimi için bu tablolara bağlıdır.

Ayrılmış geliştirme ortamları ile birden çok çözüm

Bu strateji, yönetilmeyen her çözümü kendi yalıtılmış Dataverse geliştirme ortamında geliştirmeyi içerir. Bu strateji genellikle, örneğin Satış, Müşteri Hizmetleri veya Saha Hizmeti gibi farklı uygulamaların bağımsız olarak oluşturulduğu ve korunduğu modüler mimarilerde kullanılır. Ortak bileşenleri (örneğin, hesap ve kişi tabloları) içeren bir temel çözüm oluşturulur ve uygulamaya özgü her geliştirme ortamına yönetilen bir çözüm olarak dağıtılır. Ardından her uygulamanın kendi yönetilmeyen çözümü vardır ve temel yönetilen çözümün üzerine katmanlanır ve ekiplerin temel temeli değiştirmeden işlevselliği genişletmesine olanak tanır.

Aşağıdakiler için önerilir:

• Büyük ölçekli kurumsal projeler.
• Birden çok geliştirici veya iş ortağına sahip takımlar
• Sıkı idare ve CI/CD işlem hatları gerektiren senaryolar.

Avantaj	Dezavantaj
Başkalarını etkilemeden modül ekleyerek veya güncelleştirerek sisteminizi büyütmek ve geliştirmek daha kolay.	Daha yüksek altyapı ve bakım yükü.
Birden çok ekip, birbirlerinin değişiklikleriyle çakışmadan farklı modüllerde paralel olarak çalışabilir.	Güçlü ortam stratejisi ve idaresi gerektirir.
Otomatikleştirilmiş test ve DevOps uygulamalarını uygulamak daha kolay.	Daha karmaşık dağıtım.
Özellikle yalnızca belirli bir uygulamayı dağıtmanız gerekiyorsa CI/CD işlem hatlarında daha küçük çözümlerin dağıtımı daha hızlıdır.
Değişiklikler belirli modüllere yalıtıldığında hataları veya regresyonları izlemek daha kolaydır.

Çözüm katmanlamanızı oluşturma

Not

Aşağıdaki adımlarda çözümleri oluşturmadan önce, ortamlarınızdaki tüm çözümleriniz için aynı yayımcıyı kullanın. Daha fazla bilgi: Çözüm yayımcısı

1. "Temel" geliştirme ortamında, yaygın olarak yönetilmeyen tablolar içeren ve başka tablo içermeyen temel çözümünüz vardır. Ardından bu çözümü yönetimli bir çözüm olarak dışarı aktarın.
2. Uzantı veya daha sonra temel katmanın üzerinde yer alacak "uygulama" katmanı için ikinci bir geliştirme ortamı ayarlarsınız.
3. Yönetilen temel katmanı uygulama katmanı geliştirme ortamına aktarır ve uygulama katmanı için yönetilmeyen bir çözüm oluşturursunuz.
4. Artık belirli bir "uygulama" çözümüne ek tablolar, sütunlar, tablo ilişkileri, eklentiler, akışlar vb. ekleyerek veri modelini genişletebilirsiniz. Daha sonra bu uygulama çözümünü yönetilen olarak dışarı aktarın. Uygulama çözümünün hala temel katman çözümüne bağlı olduğuna, ancak birden çok çözümü bu şekilde yönetmenin daha iyi bir yaklaşım olduğuna dikkat edin. Önce bahsedilen özel bir sütuna dayanan akışı göz önünde bulundurun. Çoğu durumda hem özel sütun hem de akış aynı uygulama çözümünde bulunur. Ancak özel sütun temel çözümün parçası olsa bile, önce bu temel çözümü tamamlayıp yönetilen olarak dağıtmanız gerekir, aksi takdirde uygulama çözümünün içindeki akış bile oluşturulamaz.
5. Üretim ortamınızda, yönetilen temel katmanı ve ardından yönetilen uygulama katmanını içeri aktarın. Bu, ortamda yönetilen çözümler arasında açık bağımlılıklar içeren iki yönetilen katman oluşturur.
6. İhtiyaç duyduğunuz kadar farklı çözümü korumak için bu düzeni yineleyin. Çözüm katmanlarınızın yönetilebilir durumda tutmak için çözümlerin sayısını olabildiğince küçük tutmanızı önerdiğimiz halde.

İlgili makaleler

Tablo segmentasyonu kullanma
Senaryo 5: Destek ekibi geliştirmesi