Aracılığıyla paylaş


Uygulamaları ve akışları varsayılan ortamdan taşıma

Bu teknik incelemede, kuruluşların ve yöneticilerin uygulamaları ve akışları için varsayılan ortamdan geçişi nasıl planlayabileceği açıklanmaktadır.

Yazarlar: Ravi Chada (Microsoft), Rui Santos (Microsoft)

Not

Tarayıcınızdan Yazdır'ı ve ardından PDF olarak kaydet'i seçerek bu teknik incelemeyi kaydedebilir veya yazdırabilirsiniz.

Varsayılan ortam

Her kiracı için bir varsayılan ortam oluşturulur ve bu kiracıdaki tüm kullanıcılar tarafından erişilebilir. Varsayılan ortam, Microsoft Entra kiracısının varsayılan bölgesine en yakın bölgede oluşturulur ve şu şekilde adlandırılır: [Microsoft Entra kiracı adı] (varsayılan). Power Apps veya Power Automate'e her yeni kullanıcı kaydolduğunda bu kullanıcılar, varsayılan ortamın Oluşturucu rolüne otomatik olarak eklenir. Varsayılan ortamın Ortam Yöneticisi rolüne hiçbir kullanıcı otomatik olarak eklenmez.

Varsayılan ortamı silemezsiniz ve varsayılan ortamı el ile yedekleyemezsiniz. Sistem yedeklemeleri sürekli olarak gerçekleşir. Varsayılan ortam 1 TB depolama kapasitesine sınırlı olur. Varsayılan ortam aşağıdaki özelliklere sahiptir:

  • 3 GB Dataverse veritabanı kapasitesi
  • 3 GB Dataverse dosya kapasitesi
  • 1 GB Dataverse günlük kapasitesi

Yeni ortamlar oluşturmadan önce gerçekleştirilen kapasite denetimi, yeni bir ortam oluşturmak için yeterli kapasiteye sahip olup olmadığınız hesaplanırken varsayılan ortamın dahil edilen depolama kapasitesini hariç tutar. Daha fazla veri depolamanız gerekirse bir üretim ortamı oluşturabilirsiniz.

Varsayılan ortamda, Microsoft 365 lisansa sahip bir kuruluşun çalışanları uygulamalar ve bulut akışları oluşturabilir. Varsayılan ortam, bu çalışanların uygulamalarını ve akışlarını oluşturmaya başlayabilmeleri için ilk deneme alanı stüdyosu haline gelir. Ortam oluşturucusu rolünü varsayılan ortamdan kaldıramayacağınız için oluşturucular kişisel üretkenlik uygulamaları ve akışlar oluşturmaya ve başkalarının yararlanması için bunları takımlarında paylaşmaya başlar. Çoğu kuruluş genellikle varsayılan ortamı Kişisel Üretkenlik olarak yeniden adlandırır.

Yöneticiler, varsayılan ortamda birçok uygulamanın ve akışın oluşturulduğunu reaktif bir şekilde keşfederler. Bir uygulama veya akışın, aşağıdaki gibi senaryolarda varsayılan ortamda olması uygun olmayabilir:

  • Bir uygulama, üretime benzer davranışta birçok kullanıcı ile paylaşılır.
  • Bir uygulama, Excel çalışma kitaplarını hassas verilerle kullanır.
  • Bir uygulama, SharePoint listelerine göre, eklemeler veya güncelleştirmeler gibi çok sayıda veri etkileşimi alıyor.
  • Bir uygulama veya akış yeni veri kaybını önleme (DLP) politikalarında izin verilmeyen bağlayıcılar kullanıyor.
  • Özel bağlayıcılar, özel bir ortamda güvenlik altına alınmak yerine, varsayılan ortamda etkinleştirilir ve kullanılır.

Yukarıdaki senaryolar dikkate alınmaya değerdir ve bu uygulamaları ve akışları varsayılan ortamdan kendi, geliştirici ortamına veya başka bir paylaşılan ortama taşımaya başlamanız gerektiğinin bir göstergesidir. Ortaya çıkacak diğer etmenler, varsayılan ortamla ilişkili sınırlamalardır.

Power Platform'u izleyen Mükemmeliyet Merkezi (CoE) takımları, bu sınırlara ulaşıldığında tepki vermeye zorlanır; sınırlara ulaşılması varsayılan ortamda çalışan uygulamaları olumsuz etkiler. Bu sınırlama, bir yöneticinin veya CoE takımının da düzenli olarak gerçekleştirmesi gereken bir şey olabilir. Bu geniş aşama bulunur:

  • Power Platform nesnelerinin tanımlanması
  • Power Platform nesnelerini taşıma
  • Power Platform nesnelerini temizleme

Uygulamalarınızı ve akışlarınızı yeni bir ortama taşımak için dışarı aktarmanın farklı yolları vardır. Çözümler, oluşturucularınızın Power Platform'da oluşturduğu neredeyse her şeyi içerebilen ve kendileriyle birlikte taşıyabilen tek bir dosyadır. Tuval uygulamaları ve bulut akışları doğrudan dışarı aktarılabilir.

Zaman içinde, Power Platform nesneler çözüm odaklı olacak şekilde gelişti. Artık uygulamalar ve akışlar varsayılan olarak çözümü görebilir, ancak bunun için elle etkinleştirme gerekir. Oluşturucular, make.powerapps.com ve make.powerautomate.com adresinden çözüm algılamayan olarak sınıflandırılabilen uygulamalar oluşturmaya devam edebilirler ve bunlar ayrı ayrı dışarı aktarılabilir veya bir çözüme eklenebilir. Çözüm ekleyerek, oluşturucu, ortamlar arasında bitiş noktalarını yapılandırmak ve dağıtmak için ortam değişkenlerinden ve bağlantı başvurularından yararlanabilir.

Hedef, tüm Power Platform bileşenlerin tek bir çözüme eklenmesini sağlamaktır ve bu, birden fazla bileşenin ortamlar arasında tek bir birim olarak kolaylıkla taşınabilmesine olanak tanır.

Power Platform nesnelerinin tanımlanması

İlk adım, taşınması veya temizlenmesi gereken uygulamaları ve akışları ve varlıkları tanımlamaktır. CoE Başlangıç Seti, tüm uygulamaların ve akışların envanterini sunar ve Power BI raporları da kullanımı belirlemeye yardımcı olur. Bu adım uygulama kullanımını değerlendirmenize yardımcı olur ve bunları etiketlemenize yardımcı olmalıdır. Alıştırmada ilerlerken başka bir ortama geçirilmesi gereken uygulamaları ve akışları etiketlediğinizden emin olun. Etiket kullanılan bağlayıcıları, kullanıcı konumunu, kullanıcı departmanını vb. temel alabilir. Bu makalede ayrıca veri kaybını önleme (DLP) uygulamalarına dayanarak temizlenmesi veya yeniden taşınması gereken öğeleri tanıma yöntemi de özetlenmiştir.

Power Platform nesnelerini taşıma

Bileşen farklı bir ortama geçirilmek üzere etiketlenmişse, uygulamayı taşımak için kullanılabilecek seçenekler vardır. hareket etkileşimli bir süreçtir ve oluşturucuyla bir düzeyde etkileşim gerektirir. Bir uygulamayı veya akışı taşımak için karmaşıklık düzeyi, uygulamayı veya akışı oluşturmak için kullanılan bileşenlerin karışımıyla birlikte artar.

Örneğin, altı ekranlı bir uygulama birden çok ekranda yer alan 10 düğme içerir. Bu 10 düğmenin her birinin ayrı bir akış çağırdığını varsayalım. Ayrıca verileri düzeltmek veya verileri başka bir sistemle tümleştirmek için tetiklenen birkaç akış da vardır. Ayrıca otomasyonun bir parçası olarak kullanılan bir AI Builder görüntü işleme modeli de olduğunu varsayalım. Böyle bir uygulamayı taşımak için, tüm bileşenlerin bir çözüme eklenmesi ve bağlantı başvurularının doğru şekilde ayarlanması ve tamamlanma onaylanmadan önce test edilmesi gerekir.

Başka bir durumda, Office 365 bağlantısı kullanan bir tuval uygulaması olduğunu varsayalım. Bu durumda, oluşturucunn çözüme yalnızca tuval uygulamasını eklemesi gerekir.

Power Platform nesnelerini temizleme

Bir bileşen temizleme için etiketlenirse iki adet ana seçenek bulunur. İlk seçenek doğrudan silmek ve ikinci seçenek ise bir yedek aldıktan sonra silmektir. Yedeklemenin ikinci durumunda, hareket eden nesnelerle çakışan bazı adımlar çakışabilir.

Örneğin, CoE Takımı yöneticileri çoğu oluşturucunun test uygulamaları oluşturduğunu ve öğrenme amaçlarıyla akış oluşturduğunu görür. Oluşturucular daha sonra uygulamadan ve akışlardan vazgeçerler; bu, kullanım ölçümlerine bakılarak onaylanabilir. Başka bir yol da bir uygulamayı karantinaya almaktır. Uygulama hakkında kimse size yaklaşmıyorsa uygulama silinebilir.

İletişim stratejisinin sağlanması önemli bir rol oynar. Yöneticilerin iletişim kurmayı planlamaları gerekir:

  • Yapımcıların uygulamayı yeni ortamda başlattığında izin vermeleri gereken bağlantılar kurmak.
  • Uygulamanın hedef ortamdan yeni URL'si.
  • Doğru ortama gitmek.

Nesnelerin yeniden bulunmasına yönelik bu çözümlerden bazıları hazırdır ve kullanıcılara Microsoft 365 ötesine kadar genişleyen veri kaynakları üzerinden uygulama oluşturma ve çalıştırma yeteneği sağlayan bağımsız Power Apps ve Power Automate lisansı gerektirebilir.

Stratejiler

Bir stratejiye dayalı olarak, uygulamaları ve akışları tanımlama ve varsayılan ortamdan taşıma işlemlerinin tüm sürecinin başarılı olma olasılığı daha yüksektir. Dikkate almanız gereken birden çok strateji vardır.

DLP stratejisi

Veri kaybını önleme (DLP) ilkeleri, kullanıcıların istemeden kuruluş verilerini açıpa çıkarmasını önlemeye ve kiracıda bilgi güvenliğinin korunmasına yardımcı olmak için bariyer işlevi görür. DLP ilkeleri, her ortam için bağlayıcıların etkinleştirildiği ve bağlayıcıların birlikte kullanılabildiği kuralları uygular. Bağlayıcılar yalnızca iş verileri, iş verilerine izin verilmeyenler veya bloke olarak sınıflandırılır. Bir bağlayıcıyı yalnızca iş verileri grubuna yerleştirirseniz, yalnızca aynı uygulama ya da akışta bulunan bu gruptaki diğer bağlayıcılarla birlikte kullanılabilir. En az bir ilkeniz olmasını öneririz.

DLP kullanılarak nesnelerinin tanımlanması

DLP ilkesi tabanlı tanımlama, uygulamalarınız ve akışlarınız için hedef ortamları tanımlamanıza yardımcı olur. DLP ile engellenen veya DLP etkinleştirmesi üzerine çalışmayı durduran iş ve iş dışı bağlayıcıların bir karmasını kullanan uygulamalar ya da akışlar olabilir.

CoE Starter Kit'in bir parçası olan DLP'den dolayı Potansiyel olarak kritik nesnelerin kesinti süresini önlemek için DLP düzenleyicisi (etki analizi) aracını bulabilirsiniz. DLP düzenleyicinin amacı, yöneticilerin mevcut ilkelerin etkisini veya ilke değişikliklerinin potansiyel etkisini görmelerini sağlamaktır. Yöneticilere etkilenen uygulamaların ve akışların ve yeni veya güncelleştirilmiş ilkelerin uygulanması durumunda devre dışı bırakılacak kaynakların görünümünü sunar. Uygulama, mevcut ilkeleri incelemek, var olan ilkeleri değiştirmek ve oluşturucularla iletişim kurarak ve uygulama veya akışları için en iyi eylem akışı hakkında onları bilgilendirerek riski azaltmak için kullanılabilir.

Etkiyi gözden geçirmek için mevcut DLP ilkelerini güncelleştirin. DLP düzenleyici hakkında daha fazla bilgi bulmak için CoE Başlangıç Setiyle kiracı hijyeni oluşturma makalesini izleyin.

DLP özelliğini açmadan önce, hangi uygulamaların ve akışların etkileneceğini belirleyebilir ve oluşturucuları uyarabilirsiniz. DLP düzenleyicisi her nesne türü için e-posta adresinden etkilenen tüm uygulamaların ve akışların bir .csv dosyası oluşturan bir listesini gönderebilir.

Etki Analizi alanında DLP düzenleyicisinin 2.0 sürümünü kullanarak, Etkilenen uygulamaları ve akışları CSV'ye aktarma seçeneğini seçin.

DLP düzenleyici 2.0 sürümünü kullanma.

Oluşturulan her csv dosyası (flow.csv ve apps.csv) şunlarla ilgili bilgiler içerir:

  1. Uygulamaların ve akışların adı.
  2. Uygulamaların ve akışların sahibi.
  3. Uygulamalar ve akışlar için OwnerEmail.
  4. Uygulamalar ve akışlar tarafından kullanılan tüm bağlantılar.
  5. Nesnenin tanımlanması için uygulamaların ve akışların kimliği.
  6. Uygulamaların ve akışların bulunduğu ortamın kimliği.

Bağlantılar'ın size uygulama veya akış tarafından kullanılan tüm bağlantıların listesini sunduğunu unutmayın. İlgili DLP'den tam olarak hangi bağlayıcının etkileneceğini belirlemeniz gerekiyorsa, şu an için bir otomasyon gerekir. Araçtaki bu durumu değiştirmeyi değerlendiriyoruz.

Bağlantıyı tanımlamak için uygulama örneği:

  1. Power Automate akışı oluşturun.

  2. Söz konusu DLP'yi belirten Kiracı DLP İlkesi Al bağlayıcısını kullanın.

  3. Sonuç olarak iki dizi vardır: iş verileri ve iş dışı veriler. Örneğin, Twitter bağlayıcısı şu kodu gösterir:

    [
      {
        "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
        "name": "Twitter",
        "type": "Microsoft.PowerApps/apis"
      }
    ……
    ]
    
  4. Bu listeden, csv uygulamasının veya akışın ad listesi Bağlantı sütunu ile eşleşen bağlayıcının adına erişebilirsiniz.

  5. Csv dosyasını Excel biçimine dönüştürerek ve kendi OneDrive'ınıza yerleştirerek, etkilenen tüm uygulamaları ve akışları Power Automate'ten okuyabilirsiniz. Bağlantıları bağlayıcı adlarıyla karşılaştıran mantığı temel alarak hangi bağlantının etkilendiğini denetleyin.

  6. Etkiye yol açan bağlantıyla bir eşleştirme yaptıktan sonra uygulama veya akış kimliği ve DLP'nin etkilediği bağlayıcıyı içeren yeni bir liste oluşturun.

  7. Gelecekteki etkiyle ilgili olarak oluşturucuya bilgilendirmek yapmak için önceki bilgileri kullanın. Uygulama veya akışın silinip silinemeyeceği ya da başka bir ortama geçirilme gereksinimi olup olmadığı hakkında oluşturucudan geri bildirim almak için Power Cards kullanabilirsiniz.

Analizinize bağlı olarak, etkilenen akışların kullanılmadığını belirlerseniz, onları karantinaya alabilir ve farklı bir ortama nasıl taşınabileceğini gösteren talimatlar içeren bir e-posta gönderebilirsiniz. Bu, bir kendin yap (DIY) kültürünü teşvik eder ve gölge BT'yi kaldırır. Bazı durumlarda, bazı nesneleri DLP dışında tutmak isteyebilirsiniz. Örneğin, oluşturulan yeni kaynaklar için belirli bir DLP uygulamak ve mevcut kaynakları dışarıda tutmayı isteyebilirsiniz. DLP kaynak muafiyeti hakkında daha fazla bilgi için bkz. DLP kaynak muafiyeti.

Etkili şekilde, ortam stratejiniz DLP aracılığıyla tanımlanır ve varsayılan ortamda geliştirilen uygulamalar ve akşlar için bir hedef sağlar.

Ortam stratejisi

Ortam stratejisinin geliştirilmesi için, ortamların ve diğer veri güvenliği katmanlarının, kuruluşunuzda üretken geliştirmeyi destekleyen bir şekilde yapılandırılması ve kaynakların güvenliğini sağlaması ve düzenlenmesi gerekir. Bunların içinde ortamı sağlamayı, erişim yönetimini ve kaynak denetimini yönetmeye yönelik bir strateji şu açıdan önemlidir:

  • Güvenli veri ve erişim.
  • Varsayılan ortamı uyumlu bir şekilde yönetin.
  • Yayılmayı önlemek ve kapasiteyi korumak için doğru ortam sayısını yönetin.
  • Sağlıklı bir uygulama yaşam döngüsü yönetimini (ALM) kolaylaştırma ve uygulama.
  • Kaynakları mantıksal bölümlerde düzenleyin.
  • Özel ortamlarda tutarak üretimde olan uygulamaları belirlemede operasyon birimini (ve yardım masasını) destekleyin.
  • Verilerin kabul edilebilir coğrafi bölgelerde (performans ve uyumluluk nedenleriyle) depolanıp iletilmesini sağlayın.
  • Geliştirilen uygulamaların yalıtılmasını sağlayın.
  • Dahili faturalama hizmetlerinin, hizmetleri kullanan son kullanıcılar veya departmanlar için etkinleştirilmesi.

Kendi kendine sürdürülebilecek ve mevcut ALM süreçlerin yer alabildiği iyi kurulmuş departmanlara sahip olmanız gerekir. Böyle durumlarda ortamlar yalıtım sağlar ve kaynakları departmana göre düzenler. Her departman için ayrı ortamlar oluşturarak gerçekleştirilebilecek bir strateji. Bu ortamlar, varsayılan ortamda uygulamalar ve akışlar için hedef haline gelir.

İletişim stratejisi

Geçiş süreci sırasında etkili iletişim çok önemlidir. İletişim geçiş işleminin tüm aşamalarında gerçekleşir. Açık iletişim, paydaşlar arasındaki anlayışı ve işbirliğini teşvik eder. Bilgilerin sorunsuz akmasını sağlayarak ilgili herkesin geçiş planları, ilerleme ve olası güçlükler hakkında bilgi sahibi olmasını sağlar.

Geçiş ve temizleme çalışmasının bir parçası olarak sürecin oluşturucular, paydaşlar ve liderler için sorunsuz olduğundan emin olun. Amaçlarınızda tutarlılık sağlayan ve dahil olan tüm kişilerle iletişimin sağlanmasına yardımcı olan, en iyi iletişimi nasıl ve hangi noktalarda kurmanız gerektiği konusunda bir strateji geliştirin. Dikkate alınması gereken bazı seçenekler:

  • Varlık izleyici olarak CoE Başlangıç Setini kullanın.
  • Çeşitli aşamalarda bildirim göndermek için özel bulut akışları ekleyin.
  • Oluşturucularla iletişim kurmak için gönderilen şablon e-postaları oluşturun.

Akılda tutulması gereken noktalar arasında şunlar bulunur:

  • Uygulamanın URL'sinde değişiklik. Uygulamanın kullanıcılarının yer işaretlerini varsayılan ortamdaki bir uygulamaya güncelleştirmesi gerekir.
  • URL tabanlı HTTP tetikleyici akışı varsa, bu akışın yine de webhook işlevi aldığından emin olmak için bağımlı akışlarda güncelleştirilmesi gerekir.
  • Taşıma hem oluşturucular hem de uygulama kullanıcıları için tamamlandıktan sonra bağlantı kurmak için ayrıntılı adımlar sağlayın. Kullanıcıların uygulamayı yeni ortamdan ilk kez başlattıklarında bağlantı oluşturma konusunda endişelenmemeleri gerekir.

İletişim kurmak üzere iyi bir başlangıç yapmak için, tek bir kullanıcının e-postası veya dağıtım listesine bırakmak yerine ölçeklenebilir ve daha gerçek zamanlı olabilecek self servis bir model gerekir. Bir SharePoint sitesi oluşturmayı planlıyorsanız dahili bir Microsoft Power Platform merkezi oluşturmak için kullanabileceğiniz bir şablon vardır. Merkez, strateji ve rehberlik hakkında bilgi edinmek için ortak bir alan haline gelir ve böylece oluşturucuların ne oluşturmaya çalıştıkları ve bunun için nereye gitmeleri gerektiği konusunda doğru kararları verebilmelerini sağlar.

CoE Başlangıç Setinde yararlanabileceğiniz etkin olmama bildirimi bileşenleri ayarlama ve Geliştirici Uyumluluk bileşenleri ayarlama gibi bazı mevcut çözüm bileşenleri bulunmaktadır. Bu bileşenler e-posta şablonlarıyla birlikte gelir ve amaçlarınıza ve varsayılan ortamdan geçiş yapma gereksinimize uyacak şekilde tekrarlanabilirler. Ek olarak, iletişim sitesinde bazı başarı hikayelerini yakalamak da iyi bir seçenektir.

Hedef Kitleler

Geçiş sürecinde genellikle iletişimde yer alan farklı hedef kitleler bulunur. En tipik önemli paydaşlar ve rolleri şunlardır:

  • Uygulama sahipleri: Uygulama sahipleri, belirli uygulamaların geliştirilmesinden, bakımından ve yönetiminden sorumlu kişiler veya ekiplerdir. Uygulamalarının işlevselliği, iş akışı ve yapılandırması hakkında kapsamlı bilgiye sahiptirler. Uygulama sahipleriyle iletişim, uygulamaya özel gereksinimlerini anlamak, geri bildirim toplamak, endişeleri ele almak ve uygulamalarının yeni ortama sorunsuz bir şekilde geçişini sağlamak için çok önemlidir.
  • Uygulama kullanıcıları: Uygulama kullanıcıları, görevlerini veya iş akışlarını gerçekleştirmek için uygulamaları düzenli olarak kullanan kişilerdir. Değişik düzeylerde teknik uzmanlığa ve uygulama bilgisine olabilirler. Uygulama kullanıcılarıyla iletişim, onları geçiş hakkında bilgilendirmek, ortaya çıkabilecek değişiklikler veya kesintilerle ilgili güncelleştirmeler sağlamak, sorunsuz bir geçiş sağlamak için eğitim veya destek sunmak ve günlük işlemleri üzerindeki etkiyi en aza indirmek için önemlidir.
  • Bölüm başkanları veya müdürleri: Bölüm başkanları veya müdürleri, kendi departmanlarının operasyonlarını ve stratejik hedeflerini denetledikleri için geçiş sürecinde önemli bir rol oynarlar. Bu kişilerin geçiş zaman çizelgesi, olası etkiler ve yararlar hakkında bilgilendirilmesi gerekir. Departman sorumlularıyla iletişim, gerekli rehberliği sağlamalarına, geçişi bölüm hedefleriyle uyumlu hale getirmelerine ve takımlar arasında sorunsuz koordinasyon sağlamalarına olanak tanır.
  • BT veya teknik ekipler: BT veya teknik ekipler, geçişin altyapısından, sistemlerinden ve genel teknik yönlerinden sorumludur. Bunlar geçiş işleminin planlanması, yürütülmesi ve desteğiyle ilgili kişilerdir. BT ekipleri ile iletişim, teknik gereksinimleri, bağımlılıkları, güvenlikle ilgili değerlendirmeleri ve başarılı bir geçiş için uygulanması gereken gerekli tüm altyapı veya yapılandırma değişikliklerini görüşmek için gereklidir.
  • Güvenlik ve uyumluluk ekipleri: Güvenlik ve uyumluluk ekipleri, geçiş sırasında veri güvenliği, gizliliği ve mevzuata uygunluğu sağlamada kritik bir rol oynar. Kılavuzluk sağlar ve hassas bilgileri korumak için uygun önlemlerin alınmasından emin olurlar. Güvenlik ve uyumluluk takımlarıyla iletişim, güvenlik gereksinimleri, şifreleme protokolleri, erişim denetimleri ve tüm geçiş süreci boyunca uyumlulukla ilgili değerlendirme konuları içermektedir.
  • Üst yönetim: Üst düzey yöneticiler veya üst düzey liderler de dahil olmak üzere üst yönetim, geçiş süreci hakkında bilgilendirilmelidir. Ayrıntılı, teknik bilgiler gerektirmeyebilirler ancak projenin amaçlarından, ilerlemelerinden ve kuruluş üzerindeki olası etkilerinden haberdar olmaları gerekir. Üst yönetimle iletişim, geçişe yönelik destek, stratejik hedeflerle uyum ve kaynak ayırma işlemlerinin sağlanmasına yardımcı olur.

Her hedef kitle için ilgili iletişim stratejilerini ve iletilerini, özel gereksinimleri, endişeleri ve teknik anlayış düzeylerini dikkate alarak uyarlamak önemlidir. Tüm paydaşlarla net ve zamanında iletişim işbirliğini teşvik eder, sorunsuz koordinasyon sağlar ve geçiş süreci sırasında olası sorunları azaltır.

Tempo

Bir geçiş işlemi sırasında paydaşlarla iletişimin hızı veya sıklığı projenin belirli ihtiyaçlarına ve dinamiklerine göre değişiklik gösterir. Paydaşları bilgilendirmek, endişelere çözüm bulmak ve geçiş boyunca uyumu sağlamak için düzenli ve tutarlı bir iletişim kurmak önemlidir. Farklı paydaşlarla iletişimin temposunun belirlenmesinde dikkat edilmesi gereken bazı hususlar şunlardır:

  • Uygulama sahipleri: Geçiş süreci boyunca uygulama sahipleriyle sık sık iletişimin sürdürülmesi önemlidir. Bu, geçiş işlemine ilişkin düzenli güncelleştirmeleri, herhangi bir endişenin ele alınması ve gerekirse karar verme aşamasına dahil olan uygulama sahiplerini içerir. İletişim sıklığı, uygulamanın karmaşıklığına ve kritikliğine bağlı olarak değişebilir, ancak sorguların düzenli olarak kontrol edilmesi ve zamanında yanıt verilmesi önerilir.
  • Uygulama kullanıcıları: Geçiş hakkında bilgi sahibi olmalarını sağlamak için uygulama kullanıcılarıyla düzenli iletişim kanalları aracılığıyla etkileşim kurun. Bu, duyuruları, e-postaları, bültenleri ve hatta özel eğitim oturumlarını veya atölye çalışmalarını içermelidir. Uygulama kullanıcıları ile iletişim sıklığı değişebilir, ancak temel kilometre taşlarında güncelleştirme sağlamak, onları etkileyebilecek değişiklikler veya aksaklıklar hakkında bilgilendirmek ve tüm süreç boyunca destek ve rehberlik sağlamak önemlidir.
  • Bölüm başkanları ve müdürleri: Bölüm başkanları ve müdürleri ile iletişim, departmanlarına geçişin önemine bağlı olarak düzenli aralıklarla veya gerektiğinde gerçekleşebilir. Genel ilerleme, zaman çizelgeleri ve takımlar üzerindeki etki hakkında düzenli güncelleştirmeler sağlayın.
  • BT veya teknik ekipler: Geçişe dahil olan BT ve teknik ekiplerle düzenli iletişim kurun. Bu, sürekli işbirliğini, teknik soru veya sorunlarla ilgili güncelleştirmeleri paylaşmayı ve gerekli yapılandırma ve değişiklikleri koordine etmeyi içerir. İletişim sıklığı genellikle planlama ve çözümleme aşamasında daha yüksektir. Uygulama aşamasında, sorunsuz koordinasyonu sağlamak için düzenli temas noktalarına veya toplantılara sahip olun.

Kaynak belirleme

Başarılı bir geçiş için kaynakların etkili bir şekilde yönetilmesi çok önemlidir. Geçiş sırasında yeniden kaynak yönetimi söz konusu olduğunda dikkate almanız gereken bazı önemli noktalar şunlardır:

  • Kaynak tanımlama: Geçiş öncesi hazırlıklar, veri geçişi, test, dağıtım, yapılandırma ve geçiş sonrası destek gibi görevlerden sorumlu kişiler veya ekipler dahil olmak üzere geçiş projesi için gereken kaynakları belirleyin. Her rol için gereken belirli becerilerii, uzmanlığı ve kullanılabilirliği belirleyin.
  • Kaynak tahsisi: Kaynağın becerileri, kullanılabilirliği ve iş yükü kapasitesine göre rollere ve görevlere kaynak atayın. Kaynakların, iş yükünü dengelemek ve proje son tarihlerini karşılamak üzere uygun şekilde ayrıldığından emin olun. Birden çok proje üzerindeki paylaşılan kaynaklar gibi, kaynak ayırmayı etkileyebilecek bağımlılıkları veya kısıtlamaları dikkate alın.
  • Beceriler Geliştirme ve Eğitim: Ekip içindeki beceriler ve bilgi boşluklarını değerlendirin ve kaynakların kendilerine verilen görevler için yeterli donanıma sahip olduğundan emin olmak için gerekli eğitim veya beceri geliştirme fırsatlarını sağlayın. Bu, eğitim oturumları, atölye çalışmaları veya ilgili kaynaklara ve belgelere erişim sağlamayı içerebilir.
  • İletişim ve işbirliği: Geçişe dahil olan kaynaklar arasında etkili iletişim ve işbirliğini teşvik edin. Tüm takım üyelerinin ortak hedefler için uyumlu olmasını, bilgilendirilmesini ve birlikte çalışmasını sağlamak için düzenli durum güncelleştirmeleri, koordinasyon toplantıları ve bilgi paylaşımını teşvik edin.
  • Acil durum planlaması: Potansiyel kaynak kısıtlamalarını veya risklerini tahmin edin ve acil durum planları geliştirin. Beklenmeyen devamsızlıklar veya kaynak sınırlamaları gibi beklenmedik sorunları azaltmak için yedek kaynakları tanımlamayın veya kritik rollerde çapraz eğitime alın.
  • Paydaş katılımı: Uygulama sahipleri, departman başkanları ve yönetim gibi paydaşları kaynak tahsisi ve zaman çizelgeleri veya çıktılar üzerindeki olası etkiler hakkında bilgilendirin. Beklentileri yönetmek ve şeffaflğı korumak için kaynak güncelleştirmelerini, ilerleme raporlarını ve yeniden kaynak oluşturma planlarında yapılan ayarlamaları düzenli olarak iletin.

Nesnelerin ayrı ayrı geçişleri

Uygulama ve çözüm arasındaki ayrım önemli bir ayrımdır. Bir uygulamayı dışarı aktarmak ve içeri aktarmak yalnızca bu nesneyi etkiler. Bir çözüm, birden çok uygulamanın, akışın ve diğer nesnelerin olabileceği bir kapsayıcıdır.

Tuval uygulamasını dışarı aktarma ve içeri aktarma (eski yöntem)

Ayrıntılı adımlar, Tuval uygulama paketini dışarı aktarma ve Tuval uygulama paketini içeri aktarma konusunda belgelenmektedir.

Bu uygulamaları dışarı aktarma yöntemi eski bir yöntemdir. Desteklense de çözümleri kullanmanızı öneririz. Çözümler tek bir kaynak yerine birden çok bileşen geçişi yapmanıza olanak tanır.

Akışi dışarı ve içeri aktarma (eski yöntem)

Aşağıdaki adımlarda akışın nasıl dışarı aktarılacağı açıklanmaktadır.

  1. "..." menü öğesini seçin, Dışarı aktar'ı ve ardından Paket (.zip) öğesini seçin.
  2. Paket için bir ad ve açıklama girin. Sonra varsayılan ayarları yapılandırabilir ve içeri aktarma aşamasında erişilebilen açıklamalar ekleyebilirsiniz.
  3. Paketi indirmek için sağ alt köşedeki Dışarı aktar düğmesini seçin. İndirme işleminiz otomatik olarak başlamazsa, İndir düğmesini seçebilirsiniz.

Aşağıdaki adımlarda akışın nasıl içeri aktarılacağı açıklanmaktadır.

  1. İçeri aktar düğmesini seçin.
  2. Paket dosyasını karşıya yükleyin ve paket ayrıntılarının gösterilmesi için ekranı bekleyin.
  3. Akış ayarlarını yapılandırırken, yeni bir akış oluşturmayı veya mevcut bir akışı paketten akış tanımıyla güncelleştirmeyi seçebilirsiniz.
  4. Akışı ayarlamak için gereken bağlantıları seçin. Tüm gerekli ayarları başarıyla yapılandırdıktan sonra İçeri aktar düğmesinin kullanılabilir hale geldiğini görmeniz gerekir.

Akışı içeri aktardıktan sonra, etkinleştirilmesi gerekir. Akışın herhangi bir bağlantı başvurusu varsa, akışı etkinleştiren kullanıcının bu bağlantılara erişimi olmalıdır. Aksi takdirde, bağlantı sahibi etkinleştirme kullanıcısına erişim izni verebilir.

Bu bulut akışlarını dışarı aktarma yöntemi eski bir yöntemdir. Desteklense de, yalnızca tek bir kaynak yerine birden çok bileşeni geçirmenize olanak veren çözümler kullanmanızı öneririz.

Model temelli bir uygulamayı dışarı ve içeri aktarma

Model temelli bir uygulama her zaman bir çözümün parçasıdır. Çözüm dosyasına (.zip) dahil edilen paketlenmiş uygulama, kaynak ortamdan başarıyla dışarı aktarılıp hedef ortama alındıktan sonra güvenlik rollerine göre kullanıcılar ile paylaşılabilir.

Ayrıntılı adım adım işlemler, Çözüm dışarı aktarma ve Çözümü içeri aktarma kapsamındadır.

Microsoft Copilot Studio botunu dışarı ve içeri aktarma

Çözümler kullanarak botları dışarı ve içeri aktarabilirsiniz. Adımların ayrıntılı listesi Çözümleri kullanarak botları dışarı ve içeri aktarma bölümünde bulunur.

Power Pages sitesini dışarı ve içeri aktarma

Geçiş sayfası, var olan yapılandırma verilerinizi Microsoft Dataverse ortamı kaynağından dışarı aktarmayı ve ardından hedef Dataverse ortamına almayı içerir. Hedef ortamda gerçekleştirilmesi gereken bazı ön koşullar vardır. Hazırlık çalışması tamamlandığında, portal yapılandırma verileri Configuration Migration tool kullanılarak dışarı aktarılabilir.

SharePoint Form uygulaması – varsayılan ortam için özel durum

SharePoint Form uygulamaları yalnızca bir ortamla ilişkilendirilebilir ve aksi yapılandırılmamışsa varsayılan ortamdadır. Tüm uygulamaların geçişi için hedef, varsayılan ortam yerine farklı bir ortam olarak ayarlanmalıdır. Mevcut özel formlar, otomatik olarak yeni belirlenen ortama geçirilmez. SharePoint özel formları için yalnızca üretim ortamları belirlenebilir. El ile yapılan işlem, tuval uygulamasını taşıma gibidir.

Microsoft Power Platform nesnelerini destekleme

Çoğu Microsoft Power Platform nesnesi zip dosyası olarak dışarı aktarılır. Değilse, en az bir dosya biçimine sahip olurlar. Bu dosyalar özgün biçiminde, bir zip dosyası veya birlikte gelen herhangi bir uzantı olarak, herhangi bir dosya depolama konumuna veya istediğiniz bir depoya eklenebilir. GitHub, Azure DevOps, SharePoint, One Drive veya tüm dosya biçimlerini destekleyen başka bir çözüm kullanılabilecek seçeneklerdir.

Toplu geçiş seçenekleri

Bir uygulamanın veya akışın geçişi, önceki gibi çalışıyorsa başarılıdır. Ancak aktarılamayan belirli öğeler vardır:

  • Akışın geçmiş çalıştırmalarıyla ilgili akış çalıştırma verileri- Akış çalıştırmalarıyla ilgili veriler yalnızca 28 gün boyunca depolanır. Verilere gereksinim duyarsanız, veri CoE Başlangıç Seti kullanılarak veya veri gölüne aktarma ayarlanmışsa dışarı aktarılıp depolanabilir. CoE Başlangıç Setinin en son sürümü, Veri Dışarı Aktarma ile kullanıldığında akış çalıştırma verilerine sahiptir.
  • Tuval uygulamasının sürümleri- Oluşturucular geliştirme sürecinde yinelendikçe birden çok sürüm oluşturulabilir. Önceki sürümler geçirilemez. Yalnızca en son sürüm geçirilebilir.
  • Uygulama veya akış tarafından ya da bağlayıcılar kullanılarak erişilen veriler - Dışarı aktarmanın bir parçası olarak yalnızca uygulama meta verileri dahil edilir.

Uygulamada veya akışta yapılan işbirliği yorumları da dahil değildir.

Bu makalede, bazı olasılıklar ana hatlarıyla verilmiştir. Karar vermeden önce, her olasılığın etkileri ve avantajlarını dikkate almak önemlidir.

Tümünü geçir – veritabanı yedekleme ve geri yükleme seçeneği

Çoğu ortam türüne benzer şekilde, varsayılan ortam da yedeklanır. Bu sistem yedeklemeleri otomatik olarak gerçekleştirilir. Varsayılan ortam için isteğe bağlı seçenek olmadığından destek isteği gerekir. Yedekleme, tüm verileri Dataverse içinde tutarak yeni bir ortama geri yüklenebilir. Bu seçenek sadece okuyucuya var olduğunu göstermek ve okuyucuyu ne zaman dikkate alınması gerektiği konusunda eğitmeye yöneliktir. Birincil seçim olarak izlenmemelidir çünkü sadece kısmi geçiş sağlar.

  • Desteklenen: Dataverse, Dynamics uygulamaları
  • Tam olarak desteklenmiyor: Canvas uygulaması, bileşen kitaplığı, özel sayfalar, Power Automate, Microsoft Copilot Studio

Tam desteklenmiyor, geçiş sırasında olası veri kaybı olabileceğini ve daha fazla adım gerektiğini gösterir.

Meta verileri ve ardından verileri geçirme

Meta verileri taşımak için çözümleri kullanmak ve ardından veri akışları, Azure Data Factory veya verileri aktarmak için başka bir araç kullanılması önerilen bir yaklaşımdır. Farklı bağlayıcılar nedeniyle başlangıçtan sonuna kadar eksiksiz otomasyon sağlanamayabilir ancak yakın yaklaşma mümkündür.

Yüksek düzeyde, adımlar şunlardır:

  1. Çözüme uygulama ekleme.
  2. Çözüme akış ekleme.
  3. Mevcut botları ekleyin.
  4. Uygulamalarda ve akışlarda bağlantı başvurularını ayarlama.
  5. Çözüm bağımlılıklarını denetleme ve nesneler ekleme.
  6. Çözüm verme.
  7. Çözümü içeri aktarın.
  8. Verileri aktarma.

Çözüm bağımlılıklarını denetleme

Hedef ortamda bir çözüm içeri aktarma işleminin başarısı, yalnızca çözüme tüm ilgili bileşenler eklendiğinde veya hedef ortamda kullanılabilir olduğunda sağlanabilir. Eksik bileşenler varsa, çözümün içeri aktarılamayabilir. Gerekli tüm bileşenlerin bulunduğunden emin olmak için, en iyi şekilde birlikte kullanılan seçenekler vardır:

  • Seçili bileşenleri çözüme el ile ekleyin. Bu durumda, bağımlı tüm bileşenlerin hedef ortamda zaten kullanılabilir olduğunu bildiğiniz varsayılmaktadır.

  • Sistemin sizin için bağımlılıkları tanımlamasına izin vermek için çözümün içindeki bağımlılıkları göster düğmesini kullanın. Tüm bağımlılıkları ekleyebilir veya yalnızca hedef ortamda var olmayan bağımlılıkları seçerek ekleyebilirsiniz.

    Firma tablosu için bağımlı bileşenlerle ilgili bir örnek gösteren resim.

Çözüme bileşen ekleme (el ile)

Bir çözümün oluşturulduğu varsayılarak, yapımcının mevcut bir uygulama, akış veya bot eklemek için varolan bileşen menüsü ekle seçeneğini kullanması gerekir.

Var olan bileşenlerin bir çözüme eklenmesini gösteren resim.

Bağlantı başvurularını ayarlama

Tuval uygulamaları ve akışlar, bağlantıları farklı işler. Akışlar tüm bağlayıcılar için bağlantı başvurularını kullanırken, tuval uygulamaları bunları yalnızca SQL Sunucu kimlik doğrulaması gibi örtük olarak paylaşılan (olmayanOAuth) bağlantılar için kullanır.

Bağlantılar yerine bağlantı başvurularını kullanmak için bür uygulamayı güncelleştirme

Bir çözüme eklendiğinde çözüm odaklı olmayan tuval uygulamaları, bağlantı başvurularını kullanmak üzere otomatik olarak yükseltilmez. Bağlantı başvuruları, yalnızca uygulamaya bir veri kaynağı eklendiği sırada tuval uygulamaları ile ilişkili olarak alınır. Uygulamaları yükseltmek için şunları yapmanız gerekir:

  1. Bir çözüme çözüm odaklı olmayan bir uygulama ekleyin.
  2. Bağlantıyı uygulamadan kaldırın.
  3. Çözümde yeni bir bağlantı başvurusu oluşturun.
  4. İlişkili bir bağlantı başvurusu içeren bir bağlantı ekleyin.

Akışı, bağlantılar yerine bağlantı başvuruları kullanacak şekilde güncelleştirme

Bir akış bir çözümde değilse bağlantılar kullanır. Bu akış bir çözüme eklenirse, başlangıçta bağlantıları kullanmaya devam eder. Akışlar, aşağıdaki iki yöntemden biriyle bağlantılar yerine bağlantılar başvuruları kullanacak şekilde güncelleştirilebilir:

  • Akış, yönetilmeyen bir çözümde dışarı aktarılır ve içeri aktarılırsa, bağlantılar bağlantı başvurularıyla birlikte kaldırılır.

  • Bir çözüm akışı açıldığında, akış ayrıntıları sayfasındaki akış denetleyicisi bağlantı başvurularını kullanmayla ilgili bir uyarı gösterir. Uyarı iletisinde Bağlantı başvurularının eklenebilmesi için bağlantıları kaldır'ı seçebileceğiniz bir eylem bulunur. Bu eylemi seçmek tetikleyiciyle ve eylemdeki eylemlerden gelen bağlantıları kaldırır ve bağlantı başvurularının seçili ve oluşturulmuş olmasına izin verir.

Çözüme nesne ekleme (otomasyon)

Uygulamaları toplu olarak bir çözüme taşımak için PowerShell komutlarını kullanabilirsiniz. Çözümlere önceden var olan tuval uygulamaları ve bulut akışları ekleme işlemi komut satırı aracılığıyla da yapılabilir. Bu seçeneği denemek için en yeni PowerShell modüllerini yükleyin. İki ana komut şunlardır: Set-PowerAppAsSolutionAware ve Set-FlowAsSolutionAware.

Modüller yüklendikten sonra kendi ortam kimliğinizi, uygulama kimliğinizi, akış kimliğinizi ve çözüm kimliğinizi ekleyin.

Tuval uygulaması için:

Set-PowerAppAsSolutionAware -EnvironmentName {Environment ID} -AppName {App ID} -SolutionId {Solution ID}

Akış için:

Set-FlowAsSolutionAware -EnvironmentName {Environment ID} -FlowName {Flow ID} - SolutionId {Solution ID}

Bağlantı başvuruları , bağlantı başvurusu tablosuna yapılan veri girişleridir. Bağlantı başvurusunu uygulamanın veya akışın bir parçası olarak kullanmak için çekirdek uygulamanın veya akış tanımının değiştirilmesi gerekir. connectionReferences düğümünü bağlantı başvurusuyla değiştirmeniz gerekir.

Çözümü içe aktarma veya dışa aktarma

Çözümlerin hazır olduğu varsayılarak, otomasyonun sonraki aşaması çeşitli yollarla yapılabilir:

  • Çözümleri el ile dışarı aktarın ve hedef ortama aktarın.

  • Birden fazla çözümü tek bir geçişte taşımak için paketleri kullanın.

  • Çözümü paketleme, çözümün paketini açma, çözümü dışarı aktarma ve çözümü içeri aktarma gibi birden çok işlemi gerçekleştirmek için Power Platform oluşturma araçları görevlerini kullanın. DevOps, uygulama yaşam döngüsü yönetimini (ALM) otomatikleştirme yeteneği sağlar ve bu görevlerin tümü Microsoft Power Platform için ALM'yi desteklemek amacıyla tasarlanmıştır.

Power Platform Komut Satırı Arabirimi (CLI) çözümleri içeri ve dışarı aktarmak için seçenekler de sağlar. Çözümle ilgili tüm komutlar çözüm oluşturmak, dışarı aktarmak ve içeri aktarmak için kullanılabilir. Verileri içeri ve dışarı aktarmak için CLI de kullanabilirsiniz.

Oluşturucu dostu bir seçenek, Power Platform için ALM'yi yaygınlaştırma amacına yönelik ardışık düzenleri kullanmaktır. ALM otomasyonu ve sürekli tümleştirme/sürekli dağıtım (CI/CD) yeteneklerini tek bir özellik hizmetine getirmek tüm oluşturucular, yöneticiler ve geliştiriciler için daha iyi bir yaklaşım olur.

Bağlantılar oluşturma (el ile)

İçeri aktarma işlemi ayarlanmadan önce hedef ortamda, uygulama veya akış için gereken eksik bağlantıları oluşturun. Bağlantılar oluşturma hakkında daha fazla bilgi için bkz. Power Automate'te bağlantıları yönetme.

Veri taşıma

Veri geçişi için el ile işlemden tam otomasyona kadar çeşitli seçenekler mevcuttur.

  • Excel çalışma kitaplarını kullanarak verileri el ile dışarı ve içeri aktarın.
  • Kaynak tablolardan veri ayıklamak ve doğrudan hedefe yazmak için bir Power Automate bulut akışı geliştirilebilir. Ancak bu, oluşturucunun Dynamics 365 Connector veya Dataverse (eski) bağlayıcısını kullanmasını gerektirir. Şu an için Dataverse bağlayıcısı ortamlar arasında bağlanmayı desteklememektedir. Bu özellik gelecekte için planlanmaktadır ve kullanıma sunulduğunda bir ortamdan diğerine veri taşımak için kullanılabilir.
  • Yapılandırma Geçiş aracı (CMT), portal geçişi için kullanılan bir araçtır, ancak normal veri geçişi için de kullanılabilir. CMT PowerShell ile de kullanılabilir. PAC CLI aracı CMT'yi çağırma olanağı da sağlar.
  • Veri akışları ortamlar arasında eşlemeler oluşturmak için ve verileri taşımak için kullanılabilir. HTTP Web bağlayıcısı Dataverse'in bir alternatifi olarak kullanılabilir.
  • Azure Data Factory, kaynaktan veri alıp hedefe eklemek için Dataverse bağlayıcısıyla birlikte kullanılabilir.

Varsayılan ortamın boyutu sınırlı olduğu göz önüne alındığında, yukarıdaki seçeneklerden biri, verileri varsayılan ortamın dışına taşımak için yeterlidir.

Temizlemeyle ilgili dikkat edilmesi gereken noktalar

Temizleme, uzun zamandır kullanılmayan ve güncelleştirilmeyen uygulamalar ve akışlar için iyi bir fikirdir. Temizlemeyle ilgili olarak, bir yöneticinin dikkate alması gereken farklı yollar vardır.

  • Veri içeri aktarma sırasına karar verin. En az bağımlı tablolar önce gider ve en çok bağımlı tablo sonda gelir.
  • Tüm alanların eşlenmesi gerekmez. Sürüm, Değiştirme tarihi, Oluşturulma tarihi ve diğer bazı sistem alanlarının eşlenmesi gerekmez.
  • Özgün Oluşturma tarihini korumak istiyorsanız, kaynak Oluşturma Tarihi alanını , hedef tablodaki OverRiddenCreatedOn alanına eşleyin.
  • Denetim verileri taşınamaz.
  • Amaçlanmadıkça, veri ekleme işlemine bağlı olarak tetiklenen iş akışlarını veya akışları etkinleştirmeyin. Bu, veri geçişi süresini artırır.

Etiketleme seçenekleri

CoE Başlangıç Setinde şu an için etiketleme seçeneği yoktur. Ancak bu, Başlangıç Seti'ne ekleyebileceğiniz bir özelleştirme olabilir.

Etiketler adlı bir tablo oluşturun ve uygulama, akışlar ve diğer envanter tabloları ile çok-çok (N:N) ilişkisi ayarlayın. Bir etiket oluşturup bu kayıtları uygun envanter öğeleriyle ilişkilendirebilirsiniz. Daha iyi bir kullanıcı deneyimi için uygulamaların, akışların ve diğer envanter tablolarının Ana formuna bir ızgara ekleyebilirsiniz. Bu seçenek başvuru tutarlılığı içerdiği için önerilir.

Her envanter tablosunda bir metin alanı oluşturun ve daha sonra kullanabileceğiniz metni (etiket) yakalamak için bunu kullanın.

Daha sabit bir liste istiyorsanız, genel bir seçenek kümesi oluşturun ve bunu tüm envater tablolarına ve formlarına da ekleyin.

Karantina seçeneği

Belirli uygulamaların gerekliliğinden emin değilseniz, bir süre için onları izole etmeyi ve bu durum sırasında karantinaya almayı deneyebilirsiniz. Uygulama yalnızca sahibi tarafından kullanılabilir. Uygun bir süre geçtikten sonra ve sahipten hiçbir yanıt alınmamışsa, bunları ortamdan kaldırabilirsiniz.

Akışlar karantina durumunu desteklemez, ancak benzer bir yaklaşım, akışı durdurarak ve sahip tarafından yeniden etkinleştirilip etkinleştirilmediğini kontrol ederek kullanılabilir.

Her iki durumda da, sahibiyle uygun iletişimin olması önemlidir.

Yalnızca Sil seçeneği

Üretkenlik kaybı yoksa ve nesneleri yeniden kullanmak isterseniz, bu seçenek en iyisidir. Çoğu test akışı ve uygulama bu kategoriye girer.

Bu durumda, nesne listesi tanımlandıktan sonra, bir PowerShell toplu işlemi geliştirilebilir ve bu toplu işleme aktarılan bir csv listesiyle bu tüm varlıklar silinir.

Uygulamaların ve akışların kimliklerini gezindikçe, bunları varsayılan ortamdan kaldırmak için aşağıdaki komut kullanılabilir.

  • Remove-AdminFlow -EnvironmentName Default-[Guid] -FlowName [Guid]
  • Remove-AdminPowerApp -AppName [Guid] -EnvironmentName [Guid]

Nesneleri yedekleme ve Silme seçeneği

Örneğin, belirli bir sezonun gereksinimini gidermeye yönelik bir Power Automate akış oluşturulduğunu ancak bunun uzun bir süredir kullanılmadığını varsayalım. Bu durumda, bileşeni silmeden önce bileşenin bir yedeğini almak iyidir.

Bileşeni yedeklemek için, dışarı aktarılan bir çözüm oluşturmak için bireysel geçiş veya toplu geçiş seçenekleri kullanılabilir. Daha sonra, bu, istediğiniz bir dosya deposuna veya bir OneDrive konuma eklenebilir.

Yedeklemenin güvenliği sağlandıktan sonra, temizleme işlemini tamamlamak için Sil seçeneğini uygulayabilirsiniz.

Çoğu durumda bunlar, kişisel üretkenlik öğrenimi ve denemelerinin bir parçası olarak oluşturucular tarafından oluşturulan test akışları ve uygulamalardır.

Sonuç

Power Platform, hem amatör geliştiricilere hem de profesyonel geliştiricilere yönelik bir araçtır. Varsayılan ortam kullanımı öncelikle Microsoft 365 ürünleri kullanarak kişisel üretkenliğe odaklanmalıdır. Diğer tüm uygulamalar ve akış geliştirme, belirlenen paylaşılan, bireysel veya geliştirici ortamlarında gerçekleşmelidir. Güçlü bir öneri, oluşturucuların uygulamalarını ve akışlarını doğru ortamda geliştirmelerine yardımcı olabilecek DLP'ye dayalı bağımsız bir ortam stratejisi geliştirmektir. Ayrıca, bir iletişim stratejisi oluşturmanın ve kullanıcılara uygulama ve akış geliştirmek için strateji, çözüm uygulama ve en iyi uygulamalar hakkında öğrenmenin self servis modellerini sağlamanın da büyük bir yararı vardır. Ek olarak, iletişim sitesinde bazı başarı hikayelerini yakalamak da iyi bir seçenektir. Dahili olarak yayımlanan başarı hikâyeleri, oluşturucuların kendileriyle fikirler arasında bağlantı kurmasına yardımcı olur ve Power Platform kullanılarak elde edilebilecek olasılıklara açık olmalarını sağlar.

Belirli nesnelerin geçişi ya da taşınması için güçlü bir yönetişim stratejisi gereklidir. Nesnelerin geçişinde bireysel ve toplu taşıma gibi çeşitli stratejiler bulunmaktadır. En uygun seçenek kuruluş ilkelerimize bağlıdır. Çözümler, uygulamanızın bileşenlerini düzenlememek ve geçişleri daha basit hale getirmek için en çok önerilen yoldur.