Test çalıştırması geçişini gerçekleştirme

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şine başlamadan önce Test çalıştırmasını hazırlama aşamasını tamamlayın.

Önemli

Sorunsuz bir geçiş işlemi sağlamak için bir veya daha fazla test aktarımı gerçekleştirin. Deneme aktarma süreci, test ve doğrulama amacıyla 45 gün sürer. 45 gün sonra test çalıştırmasının süresi dolar ve sistemden kaldırılır, bu durumda gerektiğinde yeniden başlamanız gerekir. Test çalıştırması ile üretim çalıştırması arasında ne kadar fazla süre geçerse, hizmet o kadar fazla değişebilir ve hataların ortaya çıkmasına neden olabilir, bu hatalar ise yeni bir test çalıştırması sırasında fark edilebilir. Test çalıştırması içeri aktarma işlemini gerektiği kadar yeniden çalıştırabilirsiniz. Bir içeri aktarmadaki değişikliklerin başka bir içeri aktarmada kalıcı olması mümkün olmadığından, her içeri aktarma içeri aktarılan veritabanının ilk durumundan başlar. Aşağıdaki noktaları not edin:

• Test çalıştırmalarını süresiz olarak genişletemezsiniz
• Test işleyişini üretim işleyişine dönüştüremezsiniz
• Aşağıdakilerden herhangi biri gerçekleşirse bir test çalıştırması silinir:
  • Test çalıştırma süresi zaman aşımına uğradı
  • Aynı adı taşıyan yeni bir test çalıştırılır
  • Üretim serisi başlar
  • Kuruluş, kuruluş ayarları aracılığıyla el ile silinir

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. Dosyayı 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ç an ayırın.

   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, örneğin {name} ve fabrikam kiracısına karşı çalıştırmak için, Microsoft Entra kiracınızın adını belirtirse, komut aşağıdaki örnek gibi görünecektir.

    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 işlem hattı bazında 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 politikalar bulut tabanlı sürüme aktarılmaz. Bunun yerine, varsayılan proje düzeyinde bekletme ilkeleri uygulanır. Kayıplarını önlemek için sizin için önemli olan yapıları 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 hakkında bilgi için Geçiş ve geçiş hatalarını giderme bölümüne bakın.

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. Gerçekleştirilen 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. Miras alınan modeli kullanmak istemiyorsanız bu hataları yoksayabilirsiniz. Çünkü bunlar Azure DevOps Services'e aktarmanızı engellemez. 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 instance'ınızın internet erişimi yoksa, internet erişimi olan bir makineden aracı ç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. Yardım almak için prepare komutunu kullanın, aşağıdaki komutu çalıştırın:

Migrator prepare /help

Yardım belgelerinde, Azure DevOps Server örneğinden ve uzak bir makineden Migrator komutunu çalıştırmaya yönelik yönergeler ve örnekler 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 desteklenmesini 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 Microsoft Entra test kiracısını, üretim ortamı içinse ü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 işlemleriyle 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 işlemleriyle 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 sürecin ilerleyen aşamalarında oluşturduğunuz isimle güncelleyin.
Hedef	Geçiş yapılacak yeni kuruluşun özellikleri.	Eylem gerekmez. İzleyecek alt alan işlemleriyle ilgili bilgileri gözden geçirin.
İsim	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:Asla geçişi çalıştırmadan önce bu adla bir kuruluş oluşturmayın. Kuruluş, geçiş işleminin bir parçası olarak oluşturulur.
İthalat Türü	Ç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. Diğer değerler, geçiş işlemi için planlayıcı koleksiyonu çevrimdışına almadan hemen önce olduğu gibi bırakıldı ve sonrasında değiştirildi.

Not

Test içeri aktarmaları sırasında, kuruluş adının sonuna otomatik olarak '-dryrun' eklenir; geçiş sonrasında isteğe bağlı olarak 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 özellik 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)	Deniz
Kanada	Orta Kanada	CC

Kimlik haritası kaydı

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 ya etkin ya da tarihî olabilir. Etkin kimlikler Azure DevOps Services'te oturum açabilir, ancak geçmiş kimlikler oturum açamaz.

Etkin kimlikler

Geçiş sonrası Azure DevOps Services'te kullanıcı kimliklerini ifade eden etkin kimliklerdir. 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 aktif olarak işaretlenir.

Geçmiş kimlikler

Tarihsel kimlikler, kimlik eşleme günlük dosyasında Beklenen İçeri Aktarma Durumu sütununda bu şekilde eşlenmiştir. Dosyada satır girişi olmayan kimlikler de tarihi olur. Satır girişi olmayan bir kayıt örneği, artık bir şirkette çalışmayan 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örünmeyin 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 haritalama günlüğü 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:

Microsoft Entra Connect Sync'inizin parçası olarak neden bulunmadıklarını anlamak için sizin ve Microsoft Entra yöneticinizin, Eşleşme Bulunamadı (Microsoft Entra ID Sync'i Denetle) olarak işaretlenmiş kullanıcıları araştırması gerekir.

Sütun	Açıklama
Active Directory: Kullanıcı Hesabı (Azure DevOps Server)	Azure DevOps Server'da kimlik tarafından kullanılan kullanıcı dostu görüntü adı. Bu ad, haritadaki çizginin hangi kullanıcıya referans alındığı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: İçe Aktarılacak Beklenen Kullanıcı (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 İthalat Durumu	Beklenen kullanıcı geçiş durumu: Active Directory'niz ile Microsoft Entra Kimliği arasında bir eşleşme varsa Aktif, eşleşme yoksa Tarihsel.
Doğrulama Tarihi	Kimlik kayıt günlüğünün en 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, bu satırdaki kimlik geçiş sırasında doğru bir şekilde eşlendiğinde aktif hale geldiğ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, test çalıştırması geçişini tamamlamak, etkin olarak içe aktarılan bir kimliği Microsoft Entra ID'den silmek, kimliği Microsoft Entra ID'de yeniden oluşturmak ve ardından başka bir geçiş denemesi yapmaktır. 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 güncelleştirilmesi gerekiyorsa, şirket içi Active Directory kimliğinin Microsoft Entra Kimliği ile eşitlendiğinden ve doğru yapılandırıldığından emin olmak 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, tarihî 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).
   • Microsoft Entra örneğinizde bu kimlik mevcut değil.
   • Bu kimliğe sahip olan kullanıcı artık şirkette çalışmıyor.

İlk üç nedeni ele almak için, hedeflenen şirket içi Active Directory kimliğini Microsoft Entra ID ile eşitlenecek şekilde 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.

Şirkette artık çalışmayan çalışanlar tarihsel olarak içe aktarılacağı için dördüncü nedeni yoksayabilirsiniz.

Geçmiş kimlikler (küçük takımlar)

Not

Bu bölümde önerilen kimlik geçiş stratejisini yalnızca küçük ekipler dikkate almalıdır.

Microsoft Entra Connect yapılandırılmamışsa, kimlik eşleme 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 yürütülmesi, dikkatli bir şekilde ele alınması gereken sonuçlar doğurabilir. 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 tarihsel 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 tarihsel 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ğine yeniden bağlama imkanı yoktur. Ancak kullanıcılar yine de geçiş öncesi geçmişlerini arayarak \<domain>\<Active Directory username> bulabilir.

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 bu sınırlamaları kabul etmeniz 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.

Azure DevOps Services'ta kullanıcıların Visual Studio abonelikleri otomatik olarak yükseltilmezse, test çalıştırma geçişini yeniden yapmanız 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 geçişinizi yürütmeye hazır her şeye sahipsiniz. Ekibinizle geçiş için koleksiyonu çevrimdışına almak üzere kesinti süresini planlayı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ı, geçiş işleminin koleksiyonunuz için çalıştığını doğrulamanıza olanak tanır ve üretim geçişinin başarısız olmasına neden olabilecek benzersiz veri şekilleri veya sorunları olmadığından emin olur.

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, koleksiyona ait kimlik verilerinin bir kopyasını alır ve taşıma amacıyla koleksiyonla birlikte paketler. Bu veriler olmadan, geçişin kimlik kısmı yürütülemez .

İpucu

Geçiş sırasında yapılan değişiklikleri kaybetmemek için geçiş tamamlanana kadar koleksiyonu ayırmayı unutmayın çünkü bu değişiklikler daha sonra geçirilmez. Geçiş için koleksiyonunuzu yedekledikten sonra yeniden takabilirsiniz. Ancak, yedeklemeden sonra yapılan değişiklikler geçişe dahil değildir ve bu da en güncel verilere sahip olma konusunda endişelere neden olabilir. Test çalıştırmaları için çevrimdışı ayırma kullanabilirsiniz, ancak bu işlem önerilen geçiş uygulamalarıyla uyumlu olmayabilir. Bunun etkilerini ve geçiş stratejinize nasıl uyduğunu tam olarak anlamak için çevrimdışı ayırma belgelerini gözden geçirin.

Bir test çalıştırmasında sıfır kesinti süresi tercih etmenin maliyetini değerlendirmek ö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, sadece birkaç saatlik kesinti süresi ayırarak bağımsız yedeklemenin doğrudan alınmasının nihayetinde daha avantajlı 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ı aktarma 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. SqlPackage.exe dotnet CLI veya .zip (Windows .NET 6) sürümlerini kullanmayın çünkü bu sürümler Azure DevOps Services ile uyumlu olmayan DACPAC dosyaları oluşturabilir.
• 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ı dizesine ;Encrypt=False;TrustServerCertificate=True ekleyin.

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 birer tablo oluşturularak hazırlanır. 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 yeri uzak bir sürücüye yönlendirmek, daha uzun oluşturma sürelerine 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ı yükleyin

Not

SQL Azure VM yöntemini kullanıyorsanız yalnızca bağlantı dizesi sağlamanız gerekir. Herhangi bir dosya 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 konumda bulunması 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, AzCopy veya başka bir Azure depolama gezgini aracı gibi araçlarla blob kapsayıcısını ve eşlik eden depolama hesabını silin.

Not

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

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ü geçmeyecek şekilde bir son kullanma tarihi ayarlayın.
3. Yalnızca Azure DevOps Services IP'lerine erişimi kısıtlayın.
4. SAS anahtarını bir sır olarak ele alın. Anahtarı güvenli olmayan bir konumda bırakmayın çünkü kapsayıcıda depolanan verilere okuma ve listeleme erişimi verir.

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

İşlemin önceki aşamalarında migration.json olarak bilinen geçiş belirtimi dosyasını kısmen doldurdunuz. 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: Depolama hesabına yüklediğiniz DACPAC dosyasıyla aynı ada sahip olduğundan emin olun; dosya adı .dacpac uzantısını içermelidir.

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

Geçiş türünü belirleme

İçeri aktarmalar bir test çalışması (DryRun) veya üretim çalışması (ProductionRun) olarak kuyruğa alınabilir. ImportType parametresi, geçiş türünü belirler:

• DryRun: Test çalıştırması olarak da adlandırılır. Test ve doğrulama amacıyla 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ı yapıp geçiş işlemini tamamlamanızı öneririz.

Test denemesi organizasyonları

Deneme operasyonları, ekiplerin koleksiyonlarının taşınmasını 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ırma organizasyonları sınırlı bir varoluşa sahiptir ve belirli bir süre sonunda 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.

Deneme çalıştırma organizasyonlarının silineceklerine kadar 45 günleri vardır. Belirtilen süreden sonra test çalışması organizasyonu silinir. Test çalıştırması içe aktarma işlemlerini, üretim geçişine geçmeden ö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 Kuruluşu silme bölümüne bakın.

İpucu

Kullanıcının daha başarılı olmasına yardımcı olmak için isteğe bağlı bilgiler. İlk test çalıştırmasını izleyen test çalıştırmasının geçişinin, önceki test çalıştırmalarından kaynakların temizlenmesi için gereken fazladan süre göz önüne alındığında 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 Geçiş sorunlarını ve hatalarını giderme sayfasına bakın.

Migrasyonu başlat

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ırmalarını içe aktardığınızda, bir geçişin nasıl görüneceğini önceden görebilir, olası sorunları tanımlayabilir ve üretim çalıştırmanıza başlamadan önce deneyim kazanabilirsiniz.

Not

• Geri alma işlemi gibi bir koleksiyon için tamamlanmış bir üretim hattı işlemi geçişini yinelemeniz gerekiyorsa, yeni bir geçiş kuyruğa almadan önce Azure DevOps Services Müşteri Desteği ile iletişime geçin.

• 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 Microsoft Entra kiracı ilkesi aracılığıyla kuruluş oluşturmayı kısıtlama başlığına bakın.
• Azure DevOps Services, işlem hattı başına saklama ilkelerini desteklememektedir ve bu ilkeler barındırılan sürüme aktarılmaz.

Geri alma planları için dikkat edilmesi gerekenler

Ekiplerin son üretim aşamasını yaparken sık karşılaştıkları bir endişe, geçişte bir sorun çıkması 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 dönemi 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 kapatı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. Sorun ürün grubu mühendislerinin devreye girmesini gerektiriyorsa, bu durumlar normal iş saatlerinde ele alınır.

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ı'nı kullanarak koleksiyonu Azure DevOps Server'dan (SQL'den değil) tamamen ayırmanız gerekir. Azure DevOps Server'daki ayırma işlemi, koleksiyon veritabanının dışında depolanan kullanıcı kimliği bilgilerini aktararak 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 Proje koleksiyonunu taşıma, Koleksiyonu ayırma işlemi bölümüne bakın.

Geçişi kuyruğa alın

Önemli

Öncelikle, bir DACPAC dosyası oluşturmadan veya koleksiyon veritabanını bir SQL Azure VM'sine yüklemeden önce, koleksiyonunuzun koparıldığından emin olun. Bu adımı tamamlamazsanız geçiş başarısız olur. Geçişiniz başarısız olursa bkz. geçiş hatalarını çözme.

Veri Geçiş Aracı'nın içeri aktarma komutunu kullanarak geçiş başlatın. İçeri aktarma 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. İçeri aktarma komutu bir İnternet bağlantısı gerektirir, ancak Azure DevOps Server örneğine bir 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. İçeri aktarma 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 alma komutu aşağıdaki yapıdadır.

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

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

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

Doğrulama başarılı olduktan sonra, kimlik eşleme günlük dosyasının oluşturulduğu aynı Microsoft Entra kiracısına bağlı 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 kuyruğa alınan içeri aktarma işlemleri bu üst sınırdan sayılır.

Ekibiniz bir geçiş başlattığında, geçişi kuyruğa alan kullanıcıya bir e-posta bildirimi gönderilir. Ekibiniz, geçişi kuyruğa aldıktan yaklaşık 5-10 dakika sonra, 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