Test çalıştırması geçişi yapma

Ekibiniz artık geçişinizin test çalıştırmasını başlatma ve son olarak tam üretim geçişi işlemine başlamaya hazırdır. Bu aşamada, genellikle geçiş projesinin sonunda gelen diğer görevlere ek olarak geçişi kuyruğa almak için son adımları ele aacağız.

Önkoşullar

Test çalıştırması geçişini başlatmadan önce Test çalıştırmasını hazırlama aşamasını tamamlayın.

Koleksiyonu doğrulama

Azure DevOps Services'e geçirmek istediğiniz her koleksiyonu doğrulayın. Doğrulama adımı, boyut, harmanlama, kimlik ve işlemler dahil ancak bunlarla sınırlı olmamak üzere koleksiyonunuzun çeşitli yönlerini inceler.

Veri Geçiş Aracı'nı kullanarak doğrulamayı çalıştırın.

1. Veri Geçiş Aracı'nı indirin.

2. Zip dosyasını Azure DevOps Server uygulama katmanlarınızdan birine kopyalayın.

3. Dosyanın sıkıştırmasını açın. Ayrıca, makine Azure DevOps Server örneğinin yapılandırma veritabanına bağlanabildiği sürece aracı Azure DevOps Server yüklü olmadan farklı bir makineden çalıştırabilirsiniz.

4. Sunucuda bir Komut İstemi penceresi açın ve Veri Geçiş Aracı'nın depolandığı dizine geçmek için bir cd komutu girin. Aracın yardım içeriğini gözden geçirmek için birkaç dakika bekleyin.

   a. Üst düzey yardım ve yönergeleri görüntülemek için aşağıdaki komutu çalıştırın.

    Migrator /help
   

   b. Komutun yardım metnini görüntüleyin.

    Migrator validate /help 
   

5. Bir koleksiyonu ilk kez doğrularken komutunuz aşağıdaki basit yapıya sahip olmalıdır.

    Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}
   

   Burada{name}, Örneğin DefaultCollection ve fabrikam kiracısına karşı çalıştırmak için Microsoft Entra kiracınızın adını sağlarsa, komut aşağıdaki örneğe benzer olacaktır.

    Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
   

6. Aracı Azure DevOps Sunucusu dışındaki bir makineden çalıştırmak için /connectionString parametresi gerekir. bağlantı dizesi parametresi Azure DevOps Server yapılandırma veritabanınızı gösterir. Örneğin, doğrulanmış komut Fabrikam şirketi tarafından çalıştırılırsa, komut şöyle görünür.

    Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
   

   Önemli

   Veri Geçiş Aracı koleksiyondaki hiçbir veri veya yapıyı düzenlemez . Yalnızca sorunları tanımlamak için koleksiyonu okur.

7. Doğrulama tamamlandıktan sonra günlük dosyalarını ve sonuçlarını görüntüleyebilirsiniz.

   

   Doğrulama sırasında, bazı işlem hatlarınızın işlem hattı başına saklama kuralları içeriyorsa bir uyarı alırsınız. Azure DevOps Services proje tabanlı saklama modeli kullanır ve işlem hattı başına bekletme ilkelerini desteklemez. Geçiş işlemine devam ederseniz ilkeler barındırılan sürüme taşınmaz. Bunun yerine, varsayılan proje düzeyinde bekletme ilkeleri uygulanır. Kayıplarını önlemek için sizin için önemli olan derlemeleri koruyun.

Tüm doğrulamalar geçtikten sonra geçiş işleminin bir sonraki adımına geçebilirsiniz. Veri Geçiş Aracı herhangi bir hatayı işaretlediyse, devam etmeden önce bunları düzeltin. Doğrulama hatalarını düzeltme yönergeleri için bkz . Geçiş ve geçiş hatalarını giderme.

Günlük dosyalarını içeri aktarma

Günlük dizinini açtığınızda birkaç günlük dosyası fark edebilirsiniz.

Ana günlük dosyası DataMigrationTool.log olarak adlandırılır. Çalıştırılan her şeyin ayrıntılarını içerir. Belirli alanlara odaklanmanızı kolaylaştırmak için her ana doğrulama işlemi için bir günlük oluşturulur.

Örneğin, TfsMigrator "Proje İşlemlerini Doğrulama" adımında bir hata bildirirse, ProjectProcessMap.log dosyasını açarak günlüğün tamamında gezinmek yerine bu adım için çalıştırılan her şeyi görüntüleyebilirsiniz.

TryMatchOobProcesses.log dosyasını yalnızca devralınan modeli kullanmak üzere proje işlemlerinizi geçirmeye çalışıyorsanız gözden geçirin. Devralınan modeli kullanmak istemiyorsanız, Azure DevOps Services'e aktarmanızı engellemediğinden bu hataları yoksayabilirsiniz. Daha fazla bilgi için bkz. Geçişin doğrulama aşaması.

Geçiş dosyaları oluşturma

Veri Geçiş Aracı koleksiyonu doğrulamış ve "Tüm koleksiyon doğrulamaları geçirildi" sonucunu döndürmektedir. Bir koleksiyonu geçirmek için çevrimdışına almadan önce geçiş dosyalarını oluşturun. komutunu çalıştırdığınızda prepare iki geçiş dosyası oluşturursunuz:

• IdentityMapLog.csv: Active Directory ile Microsoft Entra Id arasındaki kimlik eşlemenizi özetler.
• migration.json: Geçişinizi başlatmak için kullanmak istediğiniz geçiş belirtimini doldurmanızı gerektirir.

Hazırla komutu

prepare komutu, gerekli geçiş dosyalarının oluşturulmasına yardımcı olabilir. Temelde bu komut, kimlik eşleme günlüğünü doldurmak için tüm kullanıcıların listesini bulmak için koleksiyonu tarar IdentityMapLog.csv ve ardından her kimliğin eşleşmesini bulmak için Microsoft Entra Id'ye bağlanmaya çalışır. Bunu yapmak için şirketinizin Microsoft Entra Connect aracını (eski adıyla Dizin Eşitleme aracı, Dizin Eşitleme aracı veya DirSync.exe aracı) kullanması gerekir.

Dizin eşitlemesi ayarlanırsa, Veri Geçiş Aracı eşleşen kimlikleri bulmalı ve bunları Etkin olarak işaretlemelidir. Eşleşme yoksa kimlik, kimlik eşleme günlüğünde Geçmiş olarak işaretlenir, bu nedenle kullanıcının dizin eşitlemenize neden dahil edilmediğini araştırmanız gerekir. Migration.json geçiş belirtimi dosyası, geçiş öncesinde doldurulmalıdır.

Komutun validate aksine, prepare kimlik eşleme günlük dosyasını doldurmak için Microsoft Entra Id'ye bağlanması gerektiğinden bir internet bağlantısı gerektirir. Azure DevOps Server örneğinizin İnternet erişimi yoksa, aracı çalıştıran bir makineden çalıştırın. Azure DevOps Server örneğiniz ve İnternet bağlantınıza intranet bağlantısı olan bir makine bulabildiğiniz sürece bu komutu çalıştırabilirsiniz. Komutuyla ilgili prepare yardım için aşağıdaki komutu çalıştırın:

Migrator prepare /help

Azure DevOps Server örneğinden ve uzak makineden komutu çalıştırmaya Migrator yönelik yönergeler ve örnekler yardım belgelerinde yer alır. Komutunu Azure DevOps Server örneğinin uygulama katmanlarından birinden çalıştırıyorsanız, komutunuz aşağıdaki yapıya sahip olmalıdır:

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}

Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

connectionString parametresi, Azure DevOps Server örneğinizin yapılandırma veritabanına yönelik bir işaretçidir. Örnek olarak, Fabrikam şirketi komutu çalıştırırsa prepare , komut aşağıdaki örnekteki gibi görünür:

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

Veri Geçiş Aracı komutunu çalıştırdığında prepare , son tam doğrulamadan sonra koleksiyonunuzla ilgili hiçbir değişikliğin yapılmadığından emin olmak için eksiksiz bir doğrulama çalıştırır. Herhangi bir yeni sorun algılanırsa, hiçbir geçiş dosyası oluşturulmaz.

Komut çalışmaya başladıktan kısa süre sonra bir Microsoft Entra oturum açma penceresi görüntülenir. komutunda belirtilen kiracı etki alanına ait bir kimlikle oturum açın. Gelecekteki kuruluşunuzun yedeklenmesini istediğiniz kiracının belirtilen Microsoft Entra kiracısı olduğundan emin olun. Fabrikam örneğimizde, bir kullanıcı aşağıdaki örnek ekran görüntüsüne benzer kimlik bilgilerini girer.

Önemli

Test geçişi için test Microsoft Entra kiracısını ve üretim çalıştırması için üretim Microsoft Entra kiracınızı kullanmayın. Test amaçlı bir Microsoft Entra kiracısı kullanmak, kuruluşunuzun üretim Microsoft Entra kiracısıyla üretim çalıştırmanıza başladığınızda kimlik geçişi sorunlarına neden olabilir.

Veri Geçiş Aracı'nda komutu başarıyla çalıştırdığınızda prepare sonuçlar penceresinde bir dizi günlük ve iki geçiş dosyası görüntülenir. Günlük dizininde bir günlükler klasörü ve iki dosya bulun:

• migration.json geçiş belirtimi dosyasıdır. Doldurmak için zaman ayırmanızı öneririz.
• IdentityMapLog.csv, Active Directory'nin Microsoft Entra kimliklerine oluşturulan eşlemesini içerir. Geçişi başlatmadan önce eksiksiz olması için gözden geçirin.

İki dosya sonraki bölümlerde daha ayrıntılı olarak açıklanmıştır.

Geçiş belirtimi dosyası

Migration.json geçiş belirtimi, geçiş ayarlarını sağlayan bir JSON dosyasıdır. İstenen kuruluş adını, depolama hesabı bilgilerini ve diğer bilgileri içerir. Alanların çoğu otomatik olarak doldurulur ve geçiş denemeden önce bazı alanlar girişinizi gerektirir.

migration.json dosyasının görüntülenen alanları ve gerekli eylemleri aşağıdaki tabloda açıklanmıştır:

Alan	Açıklama	Gerekli eylem
Kaynak	Geçiş için kullanılan kaynak veri dosyalarının konumu ve adları hakkında bilgi.	Eylem gerekmez. İzleyecek alt alan eylemleriyle ilgili bilgileri gözden geçirin.
Konum	Veri katmanı uygulama paketini (DACPAC) barındıran Azure depolama hesabına paylaşılan erişim imzası anahtarı.	Eylem gerekmez. Bu alan sonraki bir adımda ele alınmıştır.
Dosyalar	Geçiş verilerini içeren dosyaların adları.	Eylem gerekmez. İzleyecek alt alan eylemleriyle ilgili bilgileri gözden geçirin.
DACPAC	Geçiş sırasında verileri getirmek için kullanılacak koleksiyon veritabanını paketleyen bir DACPAC dosyası.	Eylem gerekmez. Sonraki bir adımda, koleksiyonunuzu kullanarak bu dosyayı oluşturup bir Azure depolama hesabına yükleyebilirsiniz. Dosyayı bu işlemin ilerleyen bölümlerinde oluştururken kullandığınız ada göre güncelleştirin.
Hedef	Geçiş için yeni kuruluşun özellikleri.	Eylem gerekmez. İzleyecek alt alan eylemleriyle ilgili bilgileri gözden geçirin.
Veri Akışı Adı	Geçiş sırasında oluşturulacak kuruluşun adı.	Bir ad girin. Geçiş tamamlandıktan sonra ad hızla değiştirilebilir. NOT: Geçişi çalıştırmadan önce bu ada sahip bir kuruluş oluşturmayın. Kuruluş, geçiş işleminin bir parçası olarak oluşturulur.
ImportType	Çalıştırmak istediğiniz geçiş türü.	Eylem gerekmez. Sonraki bir adımda, çalıştırılacak geçiş türünü seçin.
Doğrulama Verileri	Geçiş deneyiminizi yönlendirmeye yardımcı olmak için gereken bilgiler.	Veri Geçiş Aracı "ValidationData" bölümünü oluşturur. Geçiş deneyiminizi yönlendirmeye yardımcı olacak bilgiler içerir. Bu bölümdeki değerleri düzenlemeyin* aksi durumda geçişiniz başlatılamaz.

Önceki işlemi tamamladıktan sonra aşağıdaki örneğe benzer bir dosyanız olmalıdır.

Yukarıdaki görüntüde, Fabrikam geçişinin planlayıcısı fabrikam-import kuruluş adını ve geçiş için coğrafi konum olarak CUS 'yi (Merkezi Birleşik Devletler) ekledi. Planlayıcı geçişi için koleksiyonu çevrimdışına almadan hemen önce değiştirilecek şekilde diğer değerler bırakıldı.

Not

Test çalıştırması içeri aktarmalarında, kuruluş adının sonuna otomatik olarak bir '-dryrun' eklenir ve geçiş sonrasında bunu değiştirebilirsiniz.

Geçiş için desteklenen Azure bölgeleri

Azure DevOps Services çeşitli Azure coğrafi konumlarında kullanılabilir. Ancak, Azure DevOps Services'ın kullanılabilir olduğu tüm konumlar geçiş için desteklenmez. Aşağıdaki tabloda geçiş için seçebileceğiniz Azure coğrafi konumları listelenir. Ayrıca, geçiş için bu coğrafyayı hedeflemek için geçiş belirtimi dosyasına yerleştirmeniz gereken değer de dahildir.

Coğrafi konum	Azure coğrafi konumu	İçeri aktarma belirtimi değeri
ABD	Merkezi Birleşik Devletler	CUS
Avrupa	Batı Avrupa	WEU
Birleşik Krallık	Güney Birleşik Krallık	UKS
Avustralya	Doğu Avustralya	EAU
Güney Amerika	Güney Brezilya	SBR
Asya Pasifik	Güney Hindistan	MA
Asya Pasifik	Güneydoğu Asya (Singapur)	SEA
Kanada	Orta Kanada	CC

Kimlik eşleme günlüğü

Kimlik eşleme günlüğü, Azure DevOps Services'e geçirdiğiniz gerçek verilere eşit öneme sahip. Dosyayı gözden geçirirken kimlik geçişinin nasıl çalıştığını ve olası sonuçların neleri kapsayabileceğini anlamanız önemlidir. Bir kimliği geçirdiğinizde, bu kimlik etkin veya geçmişe dönük olabilir. Etkin kimlikler Azure DevOps Services'te oturum açabilir, ancak geçmiş kimlikler oturum açamaz.

Etkin kimlikler

Etkin kimlikler, geçiş sonrası Azure DevOps Services'teki kullanıcı kimliklerine başvurur. Azure DevOps Services'da bu kimlikler lisanslıdır ve kuruluştaki kullanıcılar olarak görüntülenir. Kimlikler, kimlik eşleme günlük dosyasındaki Beklenen İçeri Aktarma Durumu sütununda etkin olarak işaretlenir.

Geçmiş kimlikler

Geçmiş kimlikler, kimlik eşleme günlük dosyasındaki Beklenen İçeri Aktarma Durumu sütunundaki gibi eşlenir. Dosyada satır girişi olmayan kimlikler de geçmişe dönüşür. Satır girişi olmayan bir kimlik örneği, artık bir şirkette çalışan bir çalışan olabilir.

Etkin kimliklerden farklı olarak geçmiş kimlikler:

• Geçiş sonrasında bir kuruluşa erişiminiz yok .
• Lisansınız yok .
• Kuruluşta kullanıcı olarak gösterilmeyin . Kalıcı olan tek şey, bu kimliğin kuruluştaki adının belirtilmesidir, böylece geçmişi daha sonra aranabilir. Artık şirkette çalışmayan veya kuruluşa daha fazla erişmesi gerekmeyen kullanıcılar için geçmiş kimlikleri kullanmanızı öneririz.

Not

Bir kimlik geçmiş olarak içeri aktarıldıktan sonra etkin olamaz.

Kimlik eşleme günlük dosyasını anlama

Kimlik eşlemesi günlük dosyası, burada gösterilen örneğe benzer:

Kimlik eşlemesi günlük dosyasındaki sütunlar aşağıdaki tabloda açıklanmıştır:

Sizin ve Microsoft Entra yöneticinizin, Neden Microsoft Entra Connect Sync'inizin parçası olmadığını anlamak için Eşleşme Bulunamadı (Microsoft Entra Id Sync'i Denetle) olarak işaretlenmiş kullanıcıları araştırmanız gerekir.

Sütun	Açıklama
Active Directory: Kullanıcı (Azure DevOps Server)	Azure DevOps Server'da kimlik tarafından kullanılan kolay görünen ad. Bu ad, haritadaki satırın hangi kullanıcıya başvuracaklarını belirlemeyi kolaylaştırır.
Active Directory: Güvenlik Tanımlayıcısı	Azure DevOps Server'da şirket içi Active Directory kimliği için benzersiz tanımlayıcı. Bu sütun koleksiyondaki kullanıcıları tanımlamak için kullanılır.
Microsoft Entra Id: Beklenen İçeri Aktarma Kullanıcısı (Azure DevOps Services)	Eşleştirilen yakında etkin olacak kullanıcının beklenen oturum açma adresi veya Eşleşme Bulunamadı (Microsoft Entra ID Sync'i Denetle) adresi, kimliğin Microsoft Entra ID Sync sırasında kaybolduğunu ve geçmiş olarak içeri aktarıldığını gösterir.
Beklenen İçeri Aktarma Durumu	Beklenen kullanıcı geçiş durumu: Active Directory ile Microsoft Entra Kimliği arasında bir eşleşme varsa Etkin veya eşleşme yoksa Geçmiş .
Doğrulama Tarihi	Kimlik eşleme günlüğünün son doğrulandığı zaman.

Dosyayı okurken Beklenen İçeri Aktarma Durumu sütunundaki değerin Etkin mi yoksa Geçmiş mi olduğuna dikkat edin. Etkin , geçişte bu satırdaki kimliğin doğru eşlendiğini gösterir. Geçmiş , kimliklerin geçişte geçmişe dönük hale geldiği anlamına gelir. Oluşturulan eşleme dosyasının eksiksizlik ve doğruluk açısından gözden geçirilmesi önemlidir.

Önemli

Geçiş girişimleri arasında Microsoft Entra Connect güvenlik kimliği eşitlemenizde önemli değişiklikler olursa geçiş başarısız olur. Test çalıştırmaları arasına yeni kullanıcılar ekleyebilir ve daha önce içeri aktarılan geçmiş kimliklerin etkin olmasını sağlamak için düzeltmeler yapabilirsiniz. Ancak, daha önce etkin olarak içeri aktarılan mevcut bir kullanıcıyı değiştiremezsiniz. Bunun yapılması geçişinizin başarısız olmasına neden olur. Bir değişiklik örneği, bir test çalıştırması geçişini tamamlamak, etkin olarak içeri aktarılan Microsoft Entra kimliğinizden bir kimliği silmek, aynı kimlik için Microsoft Entra Id'de yeni bir kullanıcı oluşturmak ve sonra başka bir geçiş denemesi olabilir. Bu durumda, etkin kimlik geçişi Active Directory ile yeni oluşturulan Microsoft Entra kimliği arasında denemeler gerçekleştirir, ancak geçiş hatasına neden olur.

1. Doğru eşleşen kimlikleri gözden geçirin. Tüm beklenen kimlikler mevcut mu? Kullanıcılar doğru Microsoft Entra kimliğiyle eşlendi mi?

   Herhangi bir değerin değiştirilmesi gerekiyorsa, şirket içi Active Directory kimliğinin Microsoft Entra Kimliği ile eşitlemenin bir parçası olduğunu doğrulamak ve doğru şekilde ayarlamak için Microsoft Entra yöneticinize başvurun. Daha fazla bilgi için bkz . Şirket içi kimliklerinizi Microsoft Entra Id ile tümleştirme.

2. Ardından, geçmiş olarak etiketlenmiş kimlikleri gözden geçirin. Bu etiketleme, aşağıdaki nedenlerden herhangi biri nedeniyle eşleşen bir Microsoft Entra kimliğinin bulunamadığını ifade eder:

   • Kimlik, şirket içi Active Directory ve Microsoft Entra Id arasında eşitleme için ayarlanmadı.
   • Kimlik henüz Microsoft Entra Kimliğinizde doldurulmadı (örneğin, yeni bir çalışan var).
   • Kimlik Microsoft Entra örneğinizde yok.
   • Bu kimliğe sahip olan kullanıcı artık şirkette çalışmıyor.

İlk üç nedeni ele almak için, microsoft entra id ile eşitlemek için hedeflenen şirket içi Active Directory kimliğini ayarlayın. Daha fazla bilgi için bkz . Şirket içi kimliklerinizi Microsoft Entra Id ile tümleştirme. Kimliklerin Azure DevOps Services'te etkin olarak içeri aktarılabilmesi için Microsoft Entra Connect'i ayarlamanız ve çalıştırmanız gerekir.

Artık şirkette olmayan çalışanların geçmişe dönük olarak içeri aktarılması gerektiğinden dördüncü nedeni yoksayabilirsiniz.

Geçmiş kimlikler (küçük ekipler)

Not

Bu bölümde önerilen kimlik geçiş stratejisi yalnızca küçük ekipler tarafından dikkate alınmalıdır.

Microsoft Entra Connect yapılandırılmamışsa, kimlik eşlemesi günlük dosyasındaki tüm kullanıcılar geçmiş olarak işaretlenir. Geçişin bu şekilde çalıştırılması, tüm kullanıcıların geçmiş olarak içeri aktarılmasına neden olur. Kullanıcılarınızın etkin olarak içeri aktarıldığından emin olmak için Microsoft Entra Connect'i yapılandırmanızı kesinlikle öneririz.

Tüm geçmiş kimliklerle bir geçişin çalıştırılması, dikkatli bir şekilde dikkate alınması gereken sonuçlara neden olur. Yalnızca birkaç kullanıcısı olan ve Microsoft Entra Connect'i ayarlama maliyetinin çok yüksek olduğu takımların dikkate alınması gerekir.

Tüm kimlikleri geçmiş olarak geçiş yapmak için sonraki bölümlerde açıklanan adımları izleyin. Geçişi kuyruğa aldığınızda, geçişi kuyruğa almak için kullanılan kimlik kuruluş sahibi olarak kuruluşa önyüklenir. Diğer tüm kullanıcılar geçmiş olarak içeri aktarılır. Kuruluş sahipleri daha sonra Microsoft Entra kimliklerini kullanarak kullanıcıları yeniden ekleyebilir. Eklenen kullanıcılar yeni kullanıcı olarak değerlendirilir. Geçmişlerinin hiçbirine sahip değillerdir ve bu geçmişi Microsoft Entra kimliğiyle yeniden ayrıştırma imkanı yoktur. Ancak kullanıcılar yine de kendi şirket içi geçmişlerini arayarak geçmişlerini \<domain>\<Active Directory username>arayabilir.

Veri Geçiş Aracı, geçmiş kimlikler senaryosunun tamamını algılarsa bir uyarı görüntüler. Bu geçiş yolundan gitmeye karar verirseniz, araçta sınırlamaları onaylamanız gerekir.

Visual Studio abonelikleri

Veri Geçiş Aracı, kimlik eşleme günlük dosyasını oluşturduğunda Visual Studio aboneliklerini (eski adıyla MSDN avantajları) algılayamaz. Bunun yerine, geçiş sonrasında otomatik lisans yükseltme özelliğini uygulamanızı öneririz. Kullanıcıların iş hesapları doğru şekilde bağlandığından , Azure DevOps Services geçiş sonrasında ilk oturum açma işlemlerinde Visual Studio aboneliği avantajlarını otomatik olarak uygular. Geçiş sırasında atanan lisanslar için hiçbir zaman ücret alınmaz, bu nedenle abonelikleri daha sonra güvenli bir şekilde işleyebilirsiniz.

Kullanıcıların Visual Studio abonelikleri Azure DevOps Services'ta otomatik olarak yükseltilmeyen test çalıştırması geçişlerini yinelemeniz gerekmez. Visual Studio aboneliği bağlama, geçiş kapsamı dışında gerçekleşir. İş hesapları geçiş öncesinde veya sonrasında doğru şekilde bağlandıkları sürece, kullanıcıların lisansları bir sonraki oturum açmalarında otomatik olarak yükseltilir. Lisansları başarıyla yükseltildikten sonra, bir sonraki geçiş işleminizde kullanıcılar kuruluşta ilk oturum açmalarında otomatik olarak yükseltilir.

Geçiş için hazırlanma

Artık test çalıştırması geçişinizde yürütülmeye hazır her şeye sahipsiniz. Geçişin koleksiyonunu çevrimdışına almak için ekibinizle kapalı kalma süresini zamanlayın. Geçişi çalıştırma süresini kabul ettiğinizde, oluşturduğunuz gerekli varlıkları ve veritabanının bir kopyasını Azure'a yükleyin. Geçişe hazırlanmak aşağıdaki beş adımdan oluşur.

1. Adım: Koleksiyonu çevrimdışına alın ve ayırın. 2. Adım: Geçireceğiniz koleksiyondan bir DACPAC dosyası oluşturun.
3. Adım: DACPAC dosyasını ve geçiş dosyalarını bir Azure depolama hesabına yükleyin.
4. Adım: Depolama hesabına erişmek için bir SAS belirteci oluşturun.
5. Adım: Geçiş belirtimini tamamlayın.

Not

Üretim geçişi gerçekleştirmeden önce, bir test çalıştırması geçişini tamamlamanızı kesinlikle öneririz. Test çalıştırmasıyla, geçiş işleminin koleksiyonunuz için çalıştığını ve üretim geçişi hatasına neden olabilecek benzersiz veri şekilleri olmadığını doğrulayabilirsiniz.

1. Adım: Koleksiyonunuzu ayırma

Koleksiyonu ayırmak, geçiş işleminde önemli bir adımdır. Koleksiyona ait kimlik verileri, koleksiyon ekli ve çevrimiçiyken Azure DevOps Server örneğinin yapılandırma veritabanında bulunur. Bir koleksiyon Azure DevOps Server örneğinden ayrıldığında, bu kimlik verilerinin bir kopyasını alır ve taşıma için koleksiyonla paketler. Bu veriler olmadan, geçişin kimlik kısmı yürütülemez .

İpucu

Geçiş sırasında oluşan değişiklikleri geçirmenin bir yolu olmadığından, geçiş tamamlanana kadar koleksiyonu ayrı tutmanızı öneririz. Geçiş için yedekledikten sonra koleksiyonunuzu yeniden ekleyin, böylece bu geçiş türü için en son verilere sahip olmaktan endişe duymayabilirsiniz. Çevrimdışı süreyi tamamen önlemek için, test çalıştırmaları için çevrimdışı ayırma da kullanabilirsiniz.

Bir test çalıştırması için sıfır kapalı kalma süresine neden olmak için seçme maliyetinin ağır olması önemlidir. Koleksiyon ve yapılandırma veritabanının yedeklerini almayı, bunları bir SQL örneğine geri yüklemeyi ve ardından ayrılmış bir yedekleme oluşturmayı gerektirir. Maliyet analizi, ayrılmış yedeklemenin doğrudan alınması için yalnızca birkaç saatlik kapalı kalma süresinin sonunda daha iyi olduğunu kanıtlayabilir.

2. Adım: DACPAC dosyası oluşturma

DACPACs, koleksiyonları Azure DevOps Services'e taşımak için hızlı ve nispeten kolay bir yöntem sunar. Ancak, bir koleksiyon veritabanı boyutu belirli bir eşiği aştıktan sonra, DACPAC kullanmanın avantajları azalmaya başlar.

Not

Veri Geçiş Aracı, DACPAC yöntemini kullanamamanıza ilişkin bir uyarı görüntülerse, GEÇIŞI SQL Azure sanal makinesi (VM) yöntemini kullanarak gerçekleştirmeniz gerekir. Bu durumda 2- 5 arası adımları atlayın ve Test çalıştırması hazırlama aşaması, Büyük koleksiyonları geçirme bölümündeki yönergeleri izleyin ve geçiş türünü belirlemeye devam edin. Veri Geçiş Aracı bir uyarı görüntülemiyorsa, bu adımda açıklanan DACPAC yöntemini kullanın.

DACPAC , veritabanlarının tek bir dosyada paketlenip diğer SQL Server örneklerine dağıtılmasını sağlayan bir SQL Server özelliğidir. Bir DACPAC dosyası da doğrudan Azure DevOps Services'e geri yüklenebilir, böylece koleksiyonunuzun verilerini buluta almak için paketleme yöntemi olarak kullanabilirsiniz.

Önemli

• SqlPackage.exe kullandığınızda, DACPAC'yi hazırlamak için SqlPackage.exe .NET Framework sürümünü kullanmanız gerekir. MSI Yükleyicisi, SqlPackage.exe .NET Framework sürümünü yüklemek için kullanılmalıdır. bu sürümler Azure DevOps Services ile uyumlu olmayan DACPAC'ler oluşturabileceğinden, SqlPackage.exe dotnet CLI veya .zip (Windows .NET 6) sürümlerini kullanmayın.
• SqlPackage sürüm 161, veritabanı bağlantılarını varsayılan olarak şifreler ve bağlanamayabilir. Oturum açma işlemi hatası alırsanız SqlPackage deyiminin bağlantı dizesi ekleyin;Encrypt=False;TrustServerCertificate=True.

SqlPackage sürüm notlarından en son MSI Yükleyicisi'ni kullanarak SqlPackage.exe indirip yükleyin.

MSI Yükleyicisi'ni kullandıktan sonra, SqlPackage.exe benzer %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\bir yola yüklenir.

BIR DACPAC oluşturduğunuzda iki önemli nokta göz önünde bulundurun: DACPAC'nin kaydedildiği disk ve DACPAC'yi oluşturan makinedeki disk alanı. İşlemi tamamlamak için yeterli disk alanınız olduğundan emin olmak istiyorsunuz.

Paketi oluştururken SqlPackage.exe, paketin isteğini başlatdığınız makinenin C sürücüsündeki geçici dizinde koleksiyonunuzdaki verileri geçici olarak depolar.

C sürücünüzün DACPAC oluşturmayı desteklemek için çok küçük olduğunu fark edebilirsiniz. Koleksiyon veritabanınızdaki en büyük tabloyu arayarak ihtiyacınız olan alan miktarını tahmin edebilirsiniz. DACPAC'ler bir kerede bir tablo oluşturulur. Oluşturma işlemini çalıştırmak için maksimum alan gereksinimi kabaca koleksiyonun veritabanındaki en büyük tablonun boyutuyla eşdeğerdir. Oluşturulan DACPAC'yi C sürücüsüne kaydederseniz, bir doğrulama çalıştırmasından DataMigrationTool.log dosyasında bildirilen koleksiyon veritabanının boyutunu göz önünde bulundurun.

DataMigrationTool.log dosyası, komut her çalıştırıldığında koleksiyondaki en büyük tabloların listesini sağlar. Bir koleksiyon için tablo boyutları örneği için aşağıdaki çıkışa bakın. En büyük tablonun boyutunu, geçici dizininizi barındıran sürücüdeki boş alanla karşılaştırın.

Önemli

DACPAC dosyası oluşturmaya devam etmeden önce koleksiyonunuzun ayrılmış olduğundan emin olun.

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

Geçici dizininizi barındıran sürücüde en az en az boş alan olduğundan emin olun. Aksi takdirde, ortam değişkenini ayarlayarak geçici dizini yeniden yönlendirmeniz gerekir.

SET TEMP={location on disk}

DaCPAC verilerinin nereye kaydedildiği de dikkate alınmalıdır. Kaydedilen konumu uzak bir uzak sürücüye yönlendirmek, daha uzun nesil sürelere neden olabilir. Katı hal sürücüsü (SSD) gibi hızlı bir sürücü yerel olarak kullanılabiliyorsa, DACPAC kaydetme konumu olarak sürücüyü hedeflemenizi öneririz. Aksi takdirde, uzak sürücü yerine koleksiyon veritabanının bulunduğu makinede bulunan bir diski kullanmak her zaman daha hızlıdır.

DACPAC için hedef konumu tanımladığınıza ve yeterli alana sahip olduğunuzdan emin olduğunuza göre, DACPAC dosyasını oluşturmanın zamanı geldi.

Bir Komut İstemi penceresi açın ve SqlPackage.exe konumuna gidin. DACPAC oluşturmak için yer tutucu değerlerini gerekli değerlerle değiştirin ve aşağıdaki komutu çalıştırın:

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

• Veri Kaynağı: Azure DevOps Server koleksiyon veritabanınızı barındıran SQL Server örneği.
• İlk Katalog: Koleksiyon veritabanının adı.
• targetFile: Disk üzerindeki konum ve DACPAC dosya adı.

Azure DevOps Server veri katmanında çalışan bir DACPAC oluşturma komutu aşağıdaki örnekte gösterilmiştir:

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

Komutun çıktısı, Foo.dacpac adlı koleksiyon veritabanından oluşturulan bir DACPAC dosyasıdır.

Koleksiyonunuzu geçiş için yapılandırma

Koleksiyon veritabanınız Azure VM'nize geri yüklendikten sonra, Azure DevOps Services'in verileri geçirmesi için veritabanına bağlanmasına izin vermek için bir SQL oturum açma işlemi yapılandırın. Bu oturum açma, tek bir veritabanına yalnızca okuma erişimine izin verir.

Başlamak için VM'de SQL Server Management Studio'yu açın ve ardından içeri aktarılacak veritabanında yeni bir sorgu penceresi açın.

Veritabanının kurtarmasını basit olarak ayarlayın:

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

Veritabanı için bir SQL oturumu oluşturun ve bu oturum açmayı 'TFSEXECROLE' olarak atayın:

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

Fabrikam örneğimizin ardından, iki SQL komutu aşağıdaki örneğe benzer olacaktır:

ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Not

VM'de SQL Server Management Studio'da SQL Server ve Windows kimlik doğrulama modunu etkinleştirin. Kimlik doğrulama modunu etkinleştirmezseniz geçiş başarısız olur.

Vm'yi hedeflemek için geçiş belirtimi dosyasını yapılandırma

GEÇIŞ belirtimi dosyasını SQL Server örneğine bağlanma hakkında bilgi içerecek şekilde güncelleştirin. Geçiş belirtimi dosyanızı açın ve aşağıdaki güncelleştirmeleri yapın.

1. KAYNAK dosyalar nesnesinden DACPAC parametresini kaldırın.

   Değişiklik öncesi geçiş belirtimi aşağıdaki kodda gösterilir.

   

   Değişiklik sonrasındaki geçiş belirtimi aşağıdaki kodda gösterilir.

   

2. Gerekli parametreleri doldurun ve belirtim dosyasına kaynak nesnenizin içine aşağıdaki özellikler nesnesini ekleyin.

   "Properties":
   {
       "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
   }
   

Değişiklikleri uyguladıktan sonra geçiş belirtimi aşağıdaki örneğe benzer.

Geçiş belirtiminiz artık geçiş için bir SQL Azure VM kullanacak şekilde yapılandırılmıştır. Azure DevOps Services'e geçişe yönelik diğer hazırlık adımlarıyla devam edin. Geçiş tamamlandıktan sonra SQL oturum açma işlemini sildiğinizden veya parolayı döndürdüğünüzden emin olun. Microsoft, geçiş tamamlandıktan sonra oturum açma bilgilerini tutmaz.

3. Adım: DACPAC dosyasını karşıya yükleme

Not

SQL Azure VM yöntemini kullanıyorsanız yalnızca bağlantı dizesi sağlamanız gerekir. Herhangi bir dosyayı karşıya yüklemeniz gerekmez ve bu adımı atlayabilirsiniz.

DACPAC'niz mevcut bir kapsayıcı veya geçiş çalışmalarınız için özel olarak oluşturulmuş bir kapsayıcı olabilecek bir Azure depolama kapsayıcısı içine yerleştirilmelidir. Kapsayıcınızın doğru coğrafi konumlarda oluşturulduğundan emin olmak önemlidir.

Azure DevOps Services birden çok coğrafi konumda kullanılabilir. Bu konumlara aktarırken, geçişin başarıyla başlayabilmesi için verilerinizi doğru bir şekilde yerleştirmeniz kritik önem taşır. Verilerinizin içeri aktardığınız coğrafi konuma yerleştirilmesi gerekir. Verilerin başka bir yere yerleştirilmesi, geçişin başlatılamamasıyla sonuçlanıyor. Aşağıdaki tabloda, depolama hesabınızı oluşturmak ve verilerinizi karşıya yüklemek için kabul edilebilir coğrafi konumlar listelenir.

İstenen geçiş coğrafi konumu	Depolama hesabı coğrafi konumu
Merkezi Birleşik Devletler	Merkezi Birleşik Devletler
Batı Avrupa	Batı Avrupa
Birleşik Krallık	Güney Birleşik Krallık
Doğu Avustralya	Doğu Avustralya
Güney Brezilya	Güney Brezilya
Güney Hindistan	Güney Hindistan
Orta Kanada	Orta Kanada
Asya Pasifik (Singapur)	Asya Pasifik (Singapur)

Azure DevOps Services, ABD'deki birden çok coğrafi konumda kullanılabilse de, yalnızca Orta Birleşik Devletler konumu yeni Azure DevOps Services'i kabul eder. Şu anda verilerinizi diğer ABD Azure konumlarına geçiremezsiniz.

Azure portalından bir blob kapsayıcısı oluşturun. Kapsayıcıyı oluşturduktan sonra Collection DACPAC dosyasını karşıya yükleyin.

Geçiş tamamlandıktan sonra blob kapsayıcısını ve buna eşlik eden depolama hesabını AzCopy gibi araçlarla veya Azure Depolama Gezgini gibi başka bir Azure depolama gezgini aracıyla silin.

Not

DACPAC dosyanız 10 GB'tan büyükse AzCopy kullanmanızı öneririz. AzCopy, daha hızlı karşıya yüklemeler için çok iş parçacıklı karşıya yükleme desteğine sahiptir.

4. Adım: SAS belirteci oluşturma

Paylaşılan erişim imzası (SAS) belirteci, depolama hesabındaki kaynaklara temsilci erişimi sağlar. Belirteç, Microsoft'a geçişi yürütmek üzere verilerinize erişmek için gereken en düşük ayrıcalık düzeyini vermenizi sağlar.

Azure portalını kullanarak SAS belirteçleri oluşturabilirsiniz. Güvenlik açısından aşağıdaki görevleri gerçekleştirmenizi öneririz:

1. SAS belirteciniz için yalnızca Okuma ve Listeleme izinlerini seçin. Başka izin gerekmez.
2. Gelecekte en fazla yedi gün için bir süre sonu süresi ayarlayın.
3. Yalnızca Azure DevOps Services IP'lerine erişimi kısıtlayın.
4. SAS anahtarını gizli dizi olarak ele alır. Kapsayıcıda depoladığınız verilere okuma ve liste erişimi veren anahtarı güvenli olmayan bir konumda bırakmayın.

5. Adım: Geçiş belirtimini tamamlama

İşlemin önceki bölümlerinde, migration.json olarak bilinen geçiş belirtimi dosyasını kısmen doldurduysanız. Bu noktada, geçiş türü dışında kalan tüm alanları tamamlamak için yeterli bilgiye sahipsiniz. Geçiş türü daha sonra geçiş bölümünde ele alınmıştır.

migration.json belirtim dosyasındaki Kaynak'ın altında aşağıdaki alanları doldurun.

• Konum: Betikten oluşturduğunuz ve önceki adımda kopyaladığınız SAS anahtarını yapıştırın.
• Dacpac: .dacpac dosya uzantısı da dahil olmak üzere dosyanın depolama hesabına yüklediğiniz DACPAC dosyasıyla aynı ada sahip olduğundan emin olun.

Son geçiş belirtimi dosyası aşağıdaki örneğe benzer olmalıdır.

Geçiş türünü belirleme

İçeri aktarma işlemleri bir test çalıştırması veya üretim çalıştırması olarak kuyruğa alınabilir. ImportType parametresi, geçiş türünü belirler:

• TestRun: Test amacıyla bir test çalıştırması kullanın. Sistem 45 gün sonra test çalıştırmalarını siler.
• ProductionRun: Sonuçta elde edilen geçişi korumak istediğinizde bir üretim çalıştırması kullanın ve geçiş tamamlandıktan sonra Azure DevOps Services'te kuruluşu tam zamanlı olarak kullanın.

İpucu

Her zaman önce bir test çalıştırması geçiş işlemini tamamlamanızı öneririz.

Test çalıştırması kuruluşları

Test çalıştırması kuruluşları, ekiplerin koleksiyonlarının geçişini test etmelerine yardımcı olur. Üretim geçişinin çalıştırılabilmesi için önce tamamlanmış test çalıştırması kuruluşlarının silinmesi gerekir. Tüm test çalıştırması kuruluşları sınırlı bir varoluşa sahiptir ve belirli bir süre sonra otomatik olarak silinir. Kuruluşun ne zaman silindiğiyle ilgili bilgiler, geçiş tamamlandıktan sonra almanız gereken başarı e-postasında yer alır. Bu tarihi not almayı ve buna göre planlamayı unutmayın.

Test çalıştırması kuruluşlarının silinmeden önce 45 günü vardır. Belirtilen süreden sonra test çalıştırması kuruluşu silinir. Test çalıştırması içeri aktarmalarını, üretim geçişi gerçekleştirmeden önce istediğiniz kadar tekrarlayabilirsiniz.

Test çalıştırmalarını silme

Yenisini denemeden önce önceki tüm test çalıştırmalarını silin. Ekibiniz üretim geçişi gerçekleştirmeye hazır olduğunda test çalıştırması kuruluşunu el ile silmeniz gerekir. İkinci bir test çalıştırması geçişi veya son üretim geçişi çalıştırmadan önce, önceki bir test çalıştırmasında oluşturduğunuz önceki Azure DevOps Services kuruluşlarını sildiğinizden emin olun. Daha fazla bilgi için bkz . Kuruluşu silme.

İpucu

Kullanıcının daha başarılı olmasına yardımcı olmak için isteğe bağlı bilgilerİni izleyen test çalıştırması geçişinin, önceki test çalıştırmalarından kaynakları temizlemek için gereken fazladan süre verildiğinde daha uzun sürmesi beklenir.

Kuruluş adının silindikten veya yeniden adlandırıldıktan sonra kullanılabilir duruma gelmesi bir saat kadar sürebilir. Daha fazla bilgi için Geçiş sonrası görevler makalesine bakın.

Geçiş sorunlarıyla karşılaşırsanız bkz . Geçiş ve geçiş hatalarını giderme.

Geçiş çalıştırma

Ekibiniz artık geçiş çalıştırma işlemine başlamaya hazırdır. Üretim çalıştırması geçişi denemeden önce başarılı bir test çalıştırması geçişiyle başlamanızı öneririz. Test çalıştırması içeri aktarma işlemleriyle, bir geçişin nasıl göründüğünü önceden görebilir, olası sorunları tanımlayabilir ve üretim çalıştırmanıza başlamadan önce deneyim kazanabilirsiniz.

Not

• Geri alma durumunda olduğu gibi bir koleksiyon için tamamlanmış bir üretim çalıştırması geçişini yinelemeniz gerekiyorsa, başka bir geçişi kuyruğa almadan önce Azure DevOps Services Müşteri Desteği'ne başvurun.

• Azure yöneticileri kullanıcıların yeni Azure DevOps kuruluşları oluşturmasını engelleyebilir. Microsoft Entra kiracı ilkesi açıksa geçişiniz tamamlanamıyordur. Başlamadan önce, ilkenin ayarlanmadığını veya geçişi gerçekleştiren kullanıcı için bir özel durum olduğunu doğrulayın. Daha fazla bilgi için bkz . Microsoft Entra kiracı ilkesi aracılığıyla kuruluş oluşturmayı kısıtlama.
• Azure DevOps Services, işlem hattı başına bekletme ilkelerini desteklemez ve barındırılan sürüme taşınmaz.

Geri alma planları için dikkat edilmesi gerekenler

Son üretim çalıştırmasını yapan ekiplerin sık karşılaşılan endişelerinden biri, geçişle ilgili bir sorun olması durumunda geri alma planlarıdır. Azure DevOps için Veri Geçiş Aracı'na sağladığınız geçiş ayarlarını test etmek için bir test çalıştırması yapmanızı kesinlikle öneririz.

Son üretim çalıştırması için geri alma oldukça basittir. Geçişi kuyruğa almadan önce, ekip proje koleksiyonunu Azure DevOps Server'dan ayırarak ekip üyelerinizin erişimine açık olmasını sağlayın. Herhangi bir nedenle üretim çalıştırmasını geri almanız ve ekip üyeleriniz için şirket içi sunucuyu yeniden çevrimiçi yapmanız gerekiyorsa, bunu yapabilirsiniz. Takım proje koleksiyonunu şirket içinde yeniden ekleyin ve ekibiniz olası hataları anlamak için yeniden toplanırken normal şekilde çalışmaya devam ettiklerini ekibinize bildirin.

Ardından, nedenini belirleyemiyorsanız hatanın nedenini anlama konusunda yardım almak için Azure DevOps Services müşteri desteğine başvurabilirsiniz. Daha fazla bilgi için Sorun giderme makalesine bakın. Müşteri destek biletleri aşağıdaki sayfadan https://aka.ms/AzureDevOpsImportSupportaçılabilir. Sorunun ürün grubu mühendislerinin söz konusu durumlarla ilgilenmesini gerektiriyorsa, normal iş saatlerinde ele alınacağını unutmayın.

Geçişe hazırlamak için takım projesi koleksiyonunuzu Azure DevOps Server'dan ayırma.

SQL veritabanınızın yedeğini oluşturmadan önce, Veri Geçiş Aracı koleksiyonun Azure DevOps Server'dan (SQL'den değil) tamamen ayrılmasını gerektirir. Azure DevOps Server'daki ayırma işlemi, koleksiyon veritabanının dışında depolanan kullanıcı kimliği bilgilerini aktarır ve yeni bir sunucuya veya bu durumda Azure DevOps Services'e taşınacak şekilde taşınabilir hale getirir.

Bir koleksiyonu ayırma işlemi, Azure DevOps Server örneğinizdeki Azure DevOps Server Yönetim Konsolu'ndan kolayca yapılabilir. Daha fazla bilgi için bkz . Proje koleksiyonunu taşıma, Koleksiyonu ayırma.

Geçişi kuyruğa alın

Önemli

Devam etmeden önce, BIR DACPAC dosyası oluşturmadan veya koleksiyon veritabanını BIR SQL Azure VM'ye yüklemeden önce koleksiyonunuzun ayrılmış olduğundan emin olun. Bu adımı tamamlamazsanız geçiş başarısız olur. Geçişinizin başarısız olması durumunda bkz . Geçiş hatalarını çözme.

Veri Geçiş Aracı'nın içeri aktarma komutunu kullanarak geçiş başlatın. Migration komutu giriş olarak bir geçiş belirtimi dosyası alır. Sağlanan değerlerin geçerli olduğundan emin olmak için dosyayı ayrıştırıyor ve başarılı olursa Azure DevOps Services'e geçişi kuyruğa alır. Geçiş komutu bir İnternet bağlantısı gerektirir, ancak Azure DevOps Server örneğine bağlantı gerektirmez*.

Başlamak için bir Komut İstemi penceresi açın ve dizinleri Veri Geçiş Aracı'nın yoluna değiştirin. Araçla birlikte sağlanan yardım metnini gözden geçirmenizi öneririz. Geçiş komutunun kılavuzunu ve yardımını görmek için aşağıdaki komutu çalıştırın:

Migrator import /help

Geçişi kuyruğa almak için komutu aşağıdaki yapıya sahiptir:

Migrator import /importFile:{location of migration specification file}

Aşağıdaki örnekte tamamlanmış bir geçiş komutu gösterilmektedir:

Migrator import /importFile:C:\DataMigrationToolFiles\migration.json

Doğrulama geçtikten sonra, kimlik eşleme günlük dosyasının oluşturulduğu Microsoft Entra kiracısının üyesi olan bir kimlikle Microsoft Entra Kimliği'nde oturum açın. Oturum açmış kullanıcı, içeri aktarılan kuruluşun sahibidir.

Not

Her Microsoft Entra kiracısı, 24 saatlik dönem başına beş içeri aktarma işlemiyle sınırlıdır. Yalnızca bu üst sınıra göre kuyruğa alınan içeri aktarma işlemleri.

Ekibiniz bir geçiş başlattığında, geçişi kuyruğa alan kullanıcıya bir e-posta bildirimi gönderilir. Geçişi kuyruğa aldıktan yaklaşık 5-10 dakika sonra, ekibiniz durumu denetlemek için kuruluşa gidebilir. Geçiş tamamlandıktan sonra ekibiniz oturum açmaya yönlendirilir ve kuruluş sahibine bir e-posta bildirimi gönderilir.

Veri Geçiş Aracı, geçiş öncesinde düzeltmeniz gereken hataları işaretler. Bu makalede, geçişe hazırlanırken alabileceğiniz en yaygın uyarılar ve hatalar açıklanmaktadır. Her hatayı düzeltdikten sonra çözümü doğrulamak için migrator validate komutunu yeniden çalıştırın.

Sonraki adımlar

Geçiş hatalarını düzeltme

İlgili makaleler

• Geçişe genel bakış
• Geçiş sonrası görevler