Power Platform Ortam Stratejisi: Geliştirme, Test ve Üretim Ayrımı

Power Apps ve Power Automate kullanıma açıldıktan birkaç ay sonra tablo hep aynıdır: varsayılan ortamda kimin yaptığı belli olmayan yüzlerce uygulama ve akış, kişisel hesaplara bağlı bağlantılar, bir çalışan ayrıldığı sabah duran süreçler. Araç bozuk değildir. Yönetişim baştan kurulmamıştır. Aşağıda low-code varlıkların kontrollü büyümesi için ortam yapısını, çözüm tabanlı uygulama yaşam döngüsünü (ALM), bağlayıcı DLP politikalarını ve sahipsiz kalan uygulamaların yönetimini sahada uyguladığımız sırayla anlatıyoruz.

Varsayılan ortamın sorunları

Her Power Platform kiracısında bir varsayılan ortam vardır ve silinemez. Lisanslı her kullanıcı burada uygulama ve akış oluşturabilir; Teams ve SharePoint’ten başlatılan pek çok akış da otomatik olarak buraya düşer. Kişisel üretkenlik için kullanışlıdır. Kurumsal iş uygulamaları için ise birkaç yapısal risk taşır:

• Ayrım yoktur: Geliştirme ve kullanım aynı yerde olur. Bir değişikliğin test edilmeden canlı kullanıcıya ulaşmasını engelleyen bir aşama yoktur. Cuma akşamı yapılan “küçük düzeltme” pazartesi sabahı bütün departmanı etkiler.
• Sahiplik kişiseldir: Uygulama ve bağlantılar oluşturan kullanıcıya bağlıdır. Kullanıcı ayrıldığında akışlar kimlik doğrulama hatasıyla durur.
• Envanter belirsizdir: Hangi uygulamanın günlük işi taşıdığı, hangisinin bir deneme olduğu ayırt edilemez.
• DLP en geniş kitleye uygulanmak zorundadır: Herkesin çalıştığı ortamda kısıtlayıcı politika meşru kişisel kullanımı da engeller.

Hedef varsayılan ortamı yasaklamak değil; onu “kişisel üretkenlik” alanı olarak konumlandırıp kurumsal iş uygulamalarını ayrı ortamlara taşımaktır.

Ortam türleri ve önerilen yapı

Power Platform’da varsayılan dışında üretim (production), sandbox, geliştirici (developer), deneme (trial) ve Teams için Dataverse ortamları bulunur. Sandbox ortamları kopyalama, sıfırlama ve yönetim modu gibi test işlemlerini destekler; geliştirici ortamları tek bir kullanıcıya ait kişisel çalışma alanlarıdır.

Ortam	Tür	Kim yazar	Ne içerir
Varsayılan	Varsayılan	Tüm lisanslı kullanıcılar	Kişisel üretkenlik akışları, denemeler
Geliştirme	Sandbox veya geliştirici	Uygulama ekibi	Yönetilmeyen çözümler
Test	Sandbox	Yalnız dağıtım hesabı	Yönetilen çözümler, test verisi
Üretim	Üretim	Yalnız dağıtım hesabı	Yönetilen çözümler, gerçek veri

Her uygulama için ayrı ortam üçlüsü açmak yönetim yükünü katlar. Genellikle iş alanına göre gruplama (örneğin “Operasyon”, “İK”, “Finans” için ayrı geliştirme–test–üretim setleri) artı kişisel kullanım için varsayılan ortam yeterlidir. Ortamlar arasında veri ayrımı gerekiyorsa (örneğin İK verisi) ayrı set zorunlu hâle gelir. Dataverse ile SharePoint arasındaki kaynak tercihi bu kararı etkiler; ayrıntısını Dataverse mı SharePoint listesi mi yazısında ele aldık.

Yapıyı korumak için iki kiracı ayarını ilk gün yapın: Power Platform yönetim merkezinde üretim ve sandbox ortamı oluşturma yetkisini yalnız yöneticilere verin, deneme ortamı oluşturmayı da sınırlayın. Yapmazsanız ortam sayısı da uygulama sayısı gibi kontrolsüz büyür. Lisans kapsamınız izin veriyorsa Managed Environments özelliği paylaşım sınırları, kullanım içgörüleri ve geliştiricileri kişisel geliştirici ortamlarına yönlendiren ortam yönlendirme (environment routing) gibi ek denetimler sağlar.

Çözümler, bağlantı başvuruları ve ortam değişkenleri

Ortamlar arasında taşınabilirliği çözüm (solution) sağlar. Çözüm uygulamaları, akışları, Dataverse tablolarını, güvenlik rollerini ve ilişkili bileşenleri tek paket olarak tutar. Çözüm dışında oluşturulmuş uygulama ve akışlar ortamlar arasında güvenilir biçimde taşınamaz. Sahada en sık gördüğümüz tablo, aylarca çözüm dışında büyümüş bir uygulamanın test ortamına taşınamaması ve elle yeniden kurulmasıdır. Kural basit: geliştirme ortamında her şey bir çözümün içinde oluşturulur.

Yönetilmeyen ve yönetilen çözüm

Geliştirme ortamında çözüm yönetilmeyen (unmanaged) olarak düzenlenir. Test ve üretime yönetilen (managed) olarak dışa aktarılıp içe aktarılır. Yönetilen çözüm hedef ortamda doğrudan düzenlenemez; bu, üretimde “hızlı bir düzeltme yaptım” türü kayıt dışı değişiklikleri engeller ve çözüm kaldırıldığında bileşenlerin temiz biçimde silinmesini sağlar. Üretim, düzenleme yeri değildir.

Bağlantı başvuruları

Akışlar ve uygulamalar bağlayıcılara doğrudan bir bağlantı yerine bağlantı başvurusu (connection reference) üzerinden bağlanmalıdır. Başvuru çözümün parçasıdır; gerçek bağlantı her ortamda ayrı oluşturulur. Böylece üretimdeki akışlar geliştiricinin kişisel hesabıyla değil, o ortam için tanımlanmış servis hesabının bağlantısıyla çalışır. Geliştirici izne çıkınca akış durmaz.

Ortam değişkenleri

Ortamdan ortama değişen değerler (SharePoint site adresi, liste adı, onaycı e-postası, API uç noktası) formüllere veya akış adımlarına sabit yazılmaz. Ortam değişkenleri bu değerleri çözüm içinde tanımlar, her ortamda farklı değer verilir. Testte üretim listesine yazan akış, sabit yazılmış bir adresin klasik sonucudur. Gizli bilgiler için Azure Key Vault’a başvuran gizli (secret) türünde ortam değişkeni kullanılabilir.

Geliştirmeden üretime taşıma akışı

Taşıma elle yapılabilir; ancak tekrarlanabilirlik için Power Platform CLI (pac), Power Platform’daki işlem hatları (pipelines) veya Azure DevOps/GitHub üzerindeki Power Platform Build Tools kullanın. Aşağıdaki örnek pac ile temel akışı gösterir; ortam adresleri ve çözüm adı örnektir.

# Geliştirme ortamına kimlik doğrula
pac auth create --name gelistirme --environment https://ornek-dev.crm4.dynamics.com

# Çözümü yönetilen olarak dışa aktar
pac solution export --name TalepYonetimi --path ./TalepYonetimi_managed.zip --managed

# Bağlantı başvuruları ve ortam değişkenleri için ayar dosyası üret
pac solution create-settings --solution-zip ./TalepYonetimi_managed.zip --settings-file ./uretim.settings.json

# (uretim.settings.json içindeki değerleri üretim ortamına göre doldurun)

# Üretim ortamına geç ve içe aktar
pac auth create --name uretim --environment https://ornek-prod.crm4.dynamics.com
pac solution import --path ./TalepYonetimi_managed.zip --settings-file ./uretim.settings.json

Önerdiğimiz akış şöyledir:

1. Geliştirici, geliştirme ortamında yönetilmeyen çözüm üzerinde çalışır. Çözüm kaynak kontrolüne (Git) pac solution unpack ile açılmış hâlde de kaydedilebilir; değişiklikler izlenebilir olur.
2. Sürüm hazır olduğunda çözüm sürüm numarası artırılır ve yönetilen paket üretilir.
3. Paket test ortamına ayar dosyasıyla içe aktarılır; iş birimi test senaryolarını gerçekçi veri hacmiyle doğrular.
4. Onaydan sonra aynı paket üretim ayar dosyasıyla üretime aktarılır. Test ve üretime içe aktarma kişisel hesaplarla değil, bir dağıtım hesabı veya servis sorumlusuyla yapılır.

Testte yalnız işlev değil performans da kontrol edilmelidir. Az veriyle çalışan geliştirme ortamında görünmeyen delegasyon sorunları testte ortaya çıkar, çıkmalıdır da. Bu kontroller için Power Apps delegasyon ve performans rehberindeki kontrol listesini kullanabilirsiniz.

Bağlayıcı DLP politikaları

Veri kaybı önleme (DLP) politikaları bağlayıcıları üç gruba ayırır: İş, İş dışı ve Engellenen. Bir uygulama veya akış aynı anda hem İş hem İş dışı grubundan bağlayıcı kullanamaz; Engellenen gruptakiler hiç kullanılamaz. Böylece örneğin SharePoint ve Dataverse verisinin kişisel bulut depolama veya sosyal medya bağlayıcılarına aktarılması engellenir. Bazı temel Microsoft bağlayıcıları engellenemez; bunlar yalnız İş veya İş dışı gruba alınabilir.

• Kiracı düzeyi temel politika: Tüm ortamlara, özellikle varsayılan ortama uygulanır. Kurumsal veri bağlayıcılarını İş grubuna alır, riskli bağlayıcıları engeller.
• Ortam düzeyi politika: Belirli bir iş alanının ihtiyaç duyduğu ek bağlayıcıya (örneğin ERP için özel bağlayıcı veya HTTP) yalnız o ortamda izin verir.
• HTTP ve özel bağlayıcılar: HTTP bağlayıcısı herhangi bir uç noktaya veri gönderebilir. Varsayılan ortamda engellenmeli, yalnız ihtiyaç olan ortamda açılmalıdır. Özel bağlayıcılar URL desenleriyle sınıflandırılabilir.

Sahipsiz uygulama ve akış yönetimi

Çalışan ayrıldığında hesabı devre dışı bırakılır; sahip olduğu uygulama ve akışlar sahipsiz kalır. Akışlar kişisel bağlantılarla çalışıyorsa durur, çoğu zaman kimse fark edene kadar. Kalıcı çözüm, kurumsal uygulamaları çözümlerde ve servis hesabı bağlantılarıyla çalıştırmaktır. Varsayılan ortamdaki mevcut varlıklar için ise düzenli bir süreç gerekir.

Yönetici PowerShell modülü (Microsoft.PowerApps.Administration.PowerShell) ile sahiplik raporlanır ve devredilir:

Add-PowerAppsAccount

# Bir ortamdaki uygulamaları sahipleriyle listele
Get-AdminPowerApp -EnvironmentName <ortam-id> |
    Select-Object DisplayName, AppName, @{n='Sahip';e={$_.Owner.email}}

# Uygulamanın sahipliğini yeni kullanıcıya devret
Set-AdminPowerAppOwner -EnvironmentName <ortam-id> -AppName <uygulama-id> -AppOwner <yeni-sahip-objectid>

# Akışa ikinci sahip ekle
Set-AdminFlowOwnerRole -EnvironmentName <ortam-id> -FlowName <akis-id> -PrincipalType User -PrincipalObjectId <kullanici-objectid> -RoleName CanEdit

Daha kapsamlı envanter ve otomatik bildirimler için Microsoft’un Center of Excellence (CoE) Starter Kit’i kullanılabilir. Süreç olarak şu kontrol listesi yeterli bir başlangıçtır:

• Günlük işi taşıyan her uygulama ve akışın en az iki sahibi var; sahiplerden biri ekip veya servis hesabı.
• İK’dan ayrılış bildirimi geldiğinde kullanıcının sahip olduğu uygulama ve akışlar listeleniyor ve devir yapılıyor. Hesap kapatılmadan önce, sonra değil.
• Belirli bir süredir kullanılmayan uygulamalar sahibine bildiriliyor; yanıt yoksa arşivleniyor.
• Üretimdeki akışlar kişisel bağlantı değil, bağlantı başvurusu ve servis hesabı kullanıyor.
• Yeni ortam talepleri bir form üzerinden alınıyor; amaç, sahip ve veri sınıfı kaydediliyor.

Onay akışları gibi tekil süreçlerin tasarımı bu yönetişim modelinin içinde yer alır; örnek bir tasarım için Power Automate ile onay süreçlerinin tasarımı yazısına bakabilirsiniz. Ortam yapısı, DLP ve ALM modelinin kurulması için low-code ve no-code çözüm danışmanlığı sayfamızı inceleyebilirsiniz. Ayrıntılı ALM rehberi için başvuru kaynağı Microsoft’un Power Platform ALM dokümantasyonudur.

Sık sorulan sorular

Varsayılan ortamı tamamen kapatabilir miyim?

Varsayılan ortam silinemez. Doğru yaklaşım onu kişisel üretkenlik alanı olarak kullanmak, kısıtlayıcı bir DLP politikası uygulamak ve kurumsal uygulamaları ayrı geliştirme, test ve üretim ortamlarına taşımaktır.

Her Power App için ayrı ortam açmak gerekir mi?

Gerekmez. Genellikle iş alanına göre gruplanmış geliştirme, test ve üretim setleri yeterlidir. Ayrı ortam; veri ayrımı, farklı DLP gereksinimi veya bağımsız yayın takvimi gerektiğinde açılır.

Yönetilen çözümü üretimde düzenleyebilir miyim?

Yönetilen çözümün bileşenleri hedef ortamda doğrudan düzenlenemez; bu bilinçli bir korumadır. Değişiklik geliştirme ortamındaki yönetilmeyen çözümde yapılır, sürüm artırılır ve yeni yönetilen paket testten sonra üretime aktarılır.

DLP politikası mevcut akışları bozar mı?

Yeni veya daha kısıtlayıcı bir politika, kurala aykırı bağlayıcı kombinasyonu kullanan akışları askıya alabilir. Politikayı uygulamadan önce etkilenecek varlıkları envanterden çıkarın, sahipleriyle paylaşın ve gerekirse ilgili iş alanı için ortam düzeyinde istisna tanımlayın.