Doğrulama ve içeri aktarma işlemleri

Azure DevOps Services | Azure DevOps Server | TFS

Bu makalede, bir içeri aktarmayı çalıştırmaya hazır hale Azure DevOps Services hazırlama işlemi açıklanmıştır. İşlem sırasında hatalarla karşılaşırsanız bkz. İçeri aktarma ve geçiş hatalarını giderme.

İçeri aktarma işleminizi ilerlemek için Adım adım geçiş kılavuzunu kullanmanızı öneririz. Kılavuzda teknik belgelere, araçlara ve en iyi yöntemlere bağlantılar ve bulabilirsiniz.

Koleksiyonu doğrulama

Azure DevOps Server'nin en son sürümünü çalıştırarak Azure DevOps Server onaylandıktan sonra, Azure DevOps Services'a geçirmek istediğiniz her koleksiyonu doğrulamanız gerekir.

Doğrulama adımı, koleksiyonun boyut, harmanlama, kimlik ve işlemler gibi çeşitli yönlerini inceler ancak bunlarla sınırlı değildir.

Doğrulamayı veri geçiş aracını kullanarak çalıştırabilirsiniz. Başlamak için aracı indirin,zip dosyasını uygulama katmanlarından Azure DevOps Server ve sıkıştırmayı açın. Ayrıca, makine sanal makine örneğinin yapılandırma veritabanına bağlana Azure DevOps Server yüklemeden aracı farklı bir makineden Azure DevOps Server. Bir örnek burada gösterilmiştir.

1. Sunucuda bir Komut İstemi penceresi açın ve veri geçiş aracının depolandığı dizine değiştirmek için bir cd komutu girin. Araçla birlikte sağlanan yardım içeriğini gözden geçirmek için birkaç dakika zaman alır.

   a. En üst düzey yardım ve kılavuzu görüntülemek için aşağıdaki komutu çalıştırın:

    Migrator /help
   

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

    Migrator validate /help 
   

2. Bir koleksiyonu ilk kez doğrulayana kadar basit tutabilirsiniz. Komutunuz aşağıdaki yapıya sahip olmalı:

    Migrator validate /collection:{collection URL}
   

   Örneğin, varsayılan koleksiyonda çalıştırmak için komut şöyle olabilir:

    Migrator validate /collection:http://localhost:8080/DefaultCollection
   

3. Aracı Azure DevOps Server dışında bir makineden çalıştırmak için /connectionString parametresine ihtiyacınız vardır. Bağlantı dizesi parametresi, yapılandırma veritabanınızı Azure DevOps Server gösterir. Örneğin, validate komutu Fabrikam şirketi tarafından çalıştır ediliyorsa komut şöyle olur:

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

   Önemli

   Veri geçiş aracı, koleksiyonda herhangi bir veri veya yapı düzenlemez. Yalnızca sorunları tanımlamak için koleksiyonu okur.

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

   

Tüm doğrulamalar başarılı olduktan sonra, içeri aktarma işleminin sonraki adımına geçsiniz. Veri geçiş aracı herhangi bir hata gösterirse, devam etmek için bunları düzeltmeniz gerekir. Doğrulama hatalarını düzeltme hakkında rehberlik için bkz. İçeri aktarma ve geçiş hatalarını giderme.

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

Günlük dizinini açtınız, birkaç günlük dosyası fark ettiysiniz.

Ana günlük dosyası DataMigrationTool.log olarak adlandırılmıştır. Bu dosya, çalıştırnan her şeyin ayrıntılarını içerir. Belirli alanlara odaklanmayı kolaylaştırmak için her ana doğrulama işlemi için bir günlük oluşturulur.

Örneğin, TfsMigrator "Project İşlemlerini Doğrulama" adımında bir hata raporlarsa, günlüğün tamamında kaydırma yapmak zorunda kalmadan bu adım için çalıştırıldı her şeyi görüntülemek için ProjectProcessMap.log dosyasını açabilirsiniz.

TryMatchOobProcesses.log dosyasını yalnızca devralınan modeli kullanmak üzere proje işlemlerinizi içeri aktarmaya çalışıyorsanız gözden geçirebilirsiniz. Devralınmış modeli kullanmak istemiyorsanız, bu hataları yoksayabilirsiniz çünkü bunlar, bu hataları Azure DevOps Services.

İçeri aktarma dosyaları oluşturma

Şu anda veri geçiş aracı doğrulamasını koleksiyonda çalıştırdı ve "Tüm koleksiyon doğrulamaları başarılı oldu" hatasının bir sonucu döndüren bir sonuç elde etmiş oldu. Bir koleksiyonu geçirmek için çevrimdışı duruma getirmeden önce içeri aktarma dosyalarını oluşturabilirsiniz. komutunu çalıştırarak prepare iki içeri aktarma dosyası oluşturabilirsiniz:

• IdentityMapLog.csv: Active Directory ile Azure Active Directory (Azure AD) arasındaki kimlik haritanızı özetler.
• import.json:Geçiş işlemininizi yapmak için kullanmak istediğiniz içeri aktarma belirtimini doldurmanızı gerektirir.

prepare komutu

komutu, prepare gerekli içeri aktarma dosyalarını oluşturma konusunda yardımcı olur. 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.csvve ardından her kimliğin eşleşmelerini bulmak için Azure AD'ye bağlanmaya çalışır. Bunu yapmak için, şirketinizin Azure Active Directory Bağlan aracını (eski adıyla Dizin Eşitleme aracı, Directory Sync aracı veya DirSync.exe gerekir).

Dizin eşitlemesi ayarlanırsa, veri geçiş aracının eşleşen kimlikleri bulup Bunları Etkin olarak işaretlemesi gerekir. Eşleşme bulamazsa kimlik, kimlik eşleme günlüğünde Geçmiş olarak işaretlenir ve kullanıcının neden dizin eşitlemenize dahil olmadığını araştırmanız gerekir. import.json içeri aktarma belirtimidosyası, içeri aktarmadan önce doldurulmalıdır.

Komutun validatepreparevalidate eşlemesi günlük dosyasını doldurmak için Azure AD'ye bağlanması gereken bir İnternet bağlantısı gerektirir. Azure DevOps Server örneğinizin İnternet erişimi yoksa, aracı bunu yapmak için bir makineden çalıştırmanız gerekir. Sanal makine örneğinize ve İnternet bağlantısına sahip bir intranet Azure DevOps Server bir makine bularak bu komutu çalıştırabilirsiniz. komutuyla ilgili prepare yardım için aşağıdaki komutu çalıştırın:

Migrator prepare /help

Yardım belgelerine, veri örneği ve uzak makineden Migrator'Azure DevOps Server çalıştırmaya ilişkin yönergeler ve örnekler yer almaktadır. Azure DevOps Server örneğinin uygulama katmanlarından birini kullanarak komutunu çalıştırıyorsanız, komutunuz aşağıdaki yapıya sahip olması gerekir:

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, örnek örneğinizin yapılandırma veritabanına Azure DevOps Server olur. Örneğin, komut Fabrikam şirketi tarafından çalıştır prepare ediliyorsa, komut şöyle olabilir:

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şi aracı komutu çalıştırarak, son tam doğrulamadan bu yana koleksiyonunuzla hiçbir şeyin değişmediğini sağlamak prepare için eksiksiz bir doğrulama çalıştırır. Herhangi bir yeni sorun algılanırsa, içeri aktarma dosyası oluşturulmaz.

Komut çalışmaya başladıktan kısa süre sonra bir Azure AD oturum açma penceresi görüntülenir. komutunda belirtilen kiracı etki alanına ait bir kimlikle oturum açmanız gerekir. Belirtilen Azure AD kiracısı, gelecekteki kuruluşta destek almak istediğiniz kiracı olduğundan emin olun. Fabrikam örneğimizde, bir kullanıcı aşağıdaki ekran görüntüsünde gösterilene benzer kimlik bilgilerini girer.

Veri geçişi aracında komutu başarıyla çalıştırarak sonuç penceresinde bir günlük kümesi prepare ve iki içeri aktarma dosyası görüntülenir. Günlük dizininde bir logs klasörü ve iki dosya bulabilirsiniz:

• import.json, içeri aktarma belirtimi dosyasıdır. Zaman alıp doldurmanız önerilir.
• IdentityMapLog.csv Active Directory'nin Azure AD kimlikleriyle oluşturulan eşlemesini içerir. İçeri aktarmayı başlamadan önce bütünlük için gözden geçirme.

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

İçeri aktarma belirtimi dosyası

import.json içeri aktarma belirtimi,içeri aktarma 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 doldurulr ve içeri aktarmayı denemeden önce bazı alanlar sizin girişinizi gerektirir.

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

Önceki işlemi tamamlandıktan sonra aşağıdakine benzer bir dosyanız olması gerekir:

Yukarıdaki görüntüde, Fabrikam içeri aktarma planlayıcısının fabrikam-import kuruluş adını eklemiş ve içeri aktarma bölgesi olarak CUS (Orta Birleşik Devletler) seçmiş olduğunu unutmayın. Planlayıcı geçişi için koleksiyonu çevrimdışı duruma getirmeden hemen önce değiştirilecek olan diğer değerler kaldı.

İçeri aktarma için desteklenen Azure bölgeleri

Azure DevOps Services Azure bölgelerinde kullanılabilir. Ancak, içeri aktarma için Azure DevOps Services tüm bölgeler desteklanmaz. Aşağıdaki tabloda içeri aktarma için seçerek seçerek Azure bölgeleri listelemektedir. İçeri aktarma için bu bölgeyi hedeflemek için içeri aktarma belirtimi dosyasına yer gereken değer de dahil edilir.

Kimlik eşleme günlüğü

Kimlik eşlemesi günlüğü, veri kaynağına Azure DevOps Services. Dosyayı gözden geçirerek kimlik içeri aktarmanın nasıl ilerler ve olası sonuçların neler olduğunu anlamanız önemlidir. Bir kimliği içeri aktararak etkin veya geçmiş olabilir. Etkin kimlikler, Azure DevOps Services oturum açamaz.

Etkin kimlikler

Etkin kimlikler, içeri aktarma sonrası kullanıcı olarak Azure DevOps Services kimliklere başvurur. Bu Azure DevOps Services, bu kimlikler lisanslıdır ve kuruluşta kullanıcı olarak görüntülenir. Kimlikler, kimlik eşlemesi günlükdosyasındaki Beklenen İçeri Aktarma Durumu sütununda etkin olarak işaretlenir.

Geçmiş kimlikler

Geçmiş kimlikler, kimlik eşlemesi günlük dosyasındaki Beklenen İçeri Aktarma Durumu sütunundaki gibi eşlenmiş olur. Dosyada satır girişi olmayan kimlikler de geçmiş olur. Satır girişi olmayan bir kimliğe örnek olarak, artık bir şirkette çalışan bir çalışan olabilir.

Etkin kimliklerin aksine geçmiş kimlikler:

• Geçiş sonrasında kuruluşa erişiminiz yok.
• Lisansınız yok.
• Kuruluşta kullanıcı olarak gösterme. Tek kalıcı olan, kuruluşta bu kimliğin adının daha sonra aranacak olmasıdır. Şirkette artık çalışmayan veya kuruluşa daha fazla erişim gerekmeyecek kullanıcılar için geçmiş kimlikleri kullanmalarını öneririz.

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

Kimlik eşlemesi günlük dosyası burada gösterilen örnekle benzerdir:

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

Dosyayı okurken, beklenen Içeri aktarma durumu sütunundaki değerin etkin veya Geçmişolduğunu görürsünüz. Etkin , bu satırdaki kimliğin içeri aktarma işleminde doğru bir şekilde eşlendiğini ve etkin hale geldiğini belirtir. Geçmiş , kimliklerin içeri aktarma sırasında geçmiş olacağı anlamına gelir. Üretilen eşleme dosyasını, tamamlanma ve doğruluk açısından gözden geçirmeniz önemlidir.

1. Doğru eşleşen kimlikleri inceleyerek başlayın. Beklenen tüm kimlikler var mı? Kullanıcılar doğru Azure AD kimliğiyle eşlensin mi?

   Herhangi bir değer yanlış eşlenmişse veya değiştirilmesi gerekiyorsa, şirket içi Active Directory kimliğin Azure AD 'ye eşitlemenin bir parçası olduğunu ve doğru şekilde ayarlandığını doğrulamak için Azure AD yöneticinize başvurun. Daha fazla bilgi için bkz. Şirket içi kimliklerinizi Azure Active Directory tümleştirme.

2. Sonra, Geçmişolarak etiketlenen kimlikleri gözden geçirin. Bu etiketleme, aşağıdaki nedenlerden herhangi biri için eşleşen bir Azure AD kimliğinin bulunamadığını gösterir:

   • Kimlik, şirket içi Active Directory ile Azure AD arasında eşitleme için ayarlanmadı.
   • Kimlik, Azure AD 'de henüz doldurulmadı (örneğin, yeni bir çalışan).
   • Kimlik, Azure AD örneğiniz içinde yok.
   • Bu kimliğe sahip olan Kullanıcı artık şirkette çalışmaz.

İlk üç nedeni gidermek için, Azure AD ile eşitlemek üzere amaçlanan şirket içi Active Directory kimliğini ayarlamanız gerekir. Daha fazla bilgi için bkz. Şirket içi kimliklerinizi Azure Active Directory tümleştirme. Azure DevOps Services içinde etkin olarak içeri aktarılacak kimlikler için Azure AD Connect ayarlamanız ve çalıştırmanız gerekir.

Şirket içinde artık olmayan çalışanların Geçmişolarak içeri aktarılması gerektiğinden dördüncü nedeni yoksayabilirsiniz.

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

Azure AD Connect yapılandırılmamışsa, kimlik eşleme günlük dosyasındaki tüm kullanıcıların geçmişolarak işaretlendiğini görürsünüz. Bu şekilde içeri aktarma işleminin ç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 etkinolarak içeri aktarılmasını sağlamak için Azure AD Connect yapılandırmanızı kesinlikle öneririz.

Tüm geçmiş kimliklere sahip bir içeri aktarma işleminin çalıştırılması dikkatle değerlendirilmesi gereken sonuçlara sahiptir. yalnızca az sayıda kullanıcı içeren takımlar tarafından kabul edilmelidir ve Azure AD Connect ayarlama maliyeti çok yüksek sayılır.

Tüm kimlikleri geçmiş olarak içeri aktarmak için sonraki bölümlerde özetlenen adımları izleyin. Bir içeri aktarmayı sıraya aldığınızda, içeri aktarmayı sıraya almak için kullanılan kimlik kuruluşun sahibi olarak önyüklendi. Diğer tüm kullanıcılar geçmiş olarak içeri aktarılır. Böylece, kuruluş sahipleri kullanıcıları Azure AD kimliklerini kullanarak geri ekleyebilir . Eklenen kullanıcılar yeni kullanıcı olarak kabul edilir. Bunlar geçmişlerinden herhangi birine sahip değildir ve bu GEÇMIŞI Azure AD kimliğiyle yeniden üst üste getirmenin bir yolu yoktur. Ancak, kullanıcılar, < etki alanı >< Active Directory Kullanıcı adı ' nı arayarak ön içeri aktarma geçmişlerini hala arayabilir > .

Veri geçiş aracı, tüm geçmiş kimlikler senaryosunu algılarsa bir uyarı görüntüler. Bu geçiş yolunu taşımaya karar verirseniz, bu geçişe yönelik olarak onay vermeniz gerekir.

Visual Studio abonelikleri

veri geçiş aracı, kimlik haritası günlük dosyasını oluşturduğunda Visual Studio abonelikleri (eski adıyla MSDN avantajları) algılayamaz. Bunun yerine, içeri aktarma işleminden sonra otomatik lisans yükseltme özelliğini uygulamanızı öneririz. kullanıcıların iş hesapları doğru şekilde bağlandığı sürece, Azure DevOps Services Visual Studio abonelik avantajlarını içeri aktarma işleminden sonra ilk oturum açma sırasında otomatik olarak uygular. İçeri aktarma sırasında atanan lisanslar için hiçbir ücret ödemeniz, bu nedenle daha sonra güvenle işlenebilir.

kullanıcıların Visual Studio abonelikleri Azure DevOps Services otomatik olarak yükseltilmemişse, bir kuru çalıştırma içeri aktarmayı tekrarlamanız gerekmez. Visual Studio abonelik bağlama bir içeri aktarma kapsamı dışında olur. İş hesabı içeri aktarma işleminden önce veya sonra doğru bağlanmış olduğu sürece, kullanıcıların lisansları bir sonraki oturum açma işleminde otomatik olarak yükseltilir. Lisansları başarıyla yükseltildikten sonra, bir içeri aktarma işleminin bir sonraki çalıştırılışında kullanıcılar kuruluştaki ilk oturum açtığında otomatik olarak yükseltilir.

İçeri aktarmaya hazırlanma

Şimdi içeri aktarma işleminde yürütmeye hazır olan her şey vardır. Geçiş için koleksiyonu çevrimdışına almak üzere ekiple kapalı kalma süresi zamanlamanız gerekir. İçeri aktarmayı çalıştırmak için bir zaman kabul ettiğinizde, hem oluşturduğunuz gerekli varlıkları hem de veritabanının bir kopyasını Azure 'a yüklemeniz gerekir. Bu işlemde beş adım vardır:

1. Adım: koleksiyonu çevrimdışına alın ve ayırın.

2. Adım: içeri aktaralacağınız koleksiyondan BIR DACPAC dosyası oluşturun.
3. adım: dacpac dosyasını Upload ve dosyaları bir Azure depolama hesabına aktarın.
4. Adım: depolama HESABıNA SAS anahtarı oluşturma.
5. Adım: içeri aktarma belirtimini doldurun.

1. Adım: koleksiyonunuzu ayırın

Koleksiyonu ayırmak içeri aktarma işleminde önemli bir adımdır. koleksiyon ekli ve çevrimiçi durumdayken koleksiyon için kimlik verileri Azure DevOps Server örneğinin yapılandırma veritabanında bulunur. bir koleksiyon Azure DevOps Server örneğinden ayrılmışsa, bu kimlik verilerinin bir kopyasını alır ve bunu taşıma koleksiyonuyla birlikte paketler. Bu veriler olmadan içeri aktarmanın kimlik kısmı yürütülemez. İçeri aktarma işlemi sırasında oluşan değişiklikleri içeri aktarmanın bir yolu olmadığından, koleksiyonu içeri aktarma tamamlanana kadar ayırmanız önerilir.

Bir kuru çalıştırma (test) içeri aktarma işlemi gerçekleştiriyorsanız, bu tür bir içeri aktarma için en son verileri almak konusunda endişe mayacağından, koleksiyonunuzu içeri aktarma işlemi yapıldıktan sonra yeniden iliştirmenizi öneririz. Çevrimdışı zamandan tamamen kaçınmak için, kurutma çalıştırmaları için çevrimdışı bir ayırma kullanmayı da tercih edebilirsiniz.

Bir kuru çalıştırmaya yönelik sıfır kapalı kalma süresine tabi olmak üzere seçim maliyetini belirlemek önemlidir. bu, koleksiyon ve yapılandırma veritabanının yedeklerini almayı, bir SQL örneğine geri yüklemeyi ve sonra da ayrılmış bir yedekleme oluşturmayı gerektirir. Bir maliyet analizi, ayrılan yedeklemeyi doğrudan almak için yalnızca birkaç saatlik kapalı kalma süresinin uzun süren bir şekilde daha iyi sürdüğünü kanıtlayamaz.

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

DACPACs, koleksiyonları Azure DevOps Services taşımak için hızlı ve görece kolay bir yöntem sunar. Ancak, bir koleksiyon veritabanı boyutu belirli bir eşiği aşarsa, bir DACPAC kullanmanın avantajları azalmadan başlar.

dacpac , veritabanı değişikliklerinin tek bir dosyaya paketlenmesi ve diğer SQL örneklerine dağıtılmasını sağlayan bir SQL server özelliğidir. ayrıca, bir dacpac dosyası Azure DevOps Services doğrudan geri yüklenebilir, bu sayede koleksiyon verilerini bulutta almak için paketleme yöntemi olarak kullanabilirsiniz. DACPAC dosyasını oluşturmak için SqlPackage.exe aracını kullanın. araç SQL Server Veri Araçları (ssdt)bir parçası olarak dahil edilmiştir.

SSDT ile SqlPackage.exe sürümü yüklenir. Sürümler 120, 130 ve 140 gibi adlara sahip klasörlerde depolanır. Bu SqlPackage.exe, DACPAC'i hazırlamak için doğru sürümü kullanmak önemlidir.

• TFS 2018 içeri aktarmaları, 140 SqlPackage.exe veya daha yüksek bir sürümdeki SqlPackage.exe sürümünü kullan olmalıdır.

Visual Studio için SSDT yüklemiş SqlPackage.exe aşağıdaki klasör yollarından birini kullanabilirsiniz:

• SSDT'yi yüklemiş ve var olan bir Visual Studio ile tümleştirmiş SqlPackage.exe klasör yolunuz ile C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\ benzerdir.
• SSDT'yi tek başına yükleme olarak yüklemiş SqlPackage.exe klasör yolunuz ile C:\Program Files (x86)\Microsoft Visual. Studio\2017\SQL\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\ benzerdir.
• Zaten bir dosya yüklemesi SQL Server, SqlPackage.exe zaten mevcut olabilir ve klasör yolunuz ile %PROGRAMFILES%\Microsoft SQL Server\130\DAC\bin\ benzerdir.

Hem 130 hem de 140 klasörden SQL Server Veri Araçları SSDT'nin her iki sürümü de SqlPackage.exe içerir.

BIR DACPAC oluşturma hakkında dikkat edilmesi gereken iki nokta vardır: DACPAC'nin kaydedecek olduğu disk ve DACPAC'yi oluşturan makinede disk alanı. işlemi tamamlamak için yeterli disk alanı olduğundan emin olmak istiyor.

Paketi oluşturduğunda, SqlPackage.exe paketin başlatıldığını makinenin C sürücüsündeki geçici dizinde geçici olarak depolar.

C sürücünizin DACPAC oluşturmayı desteklemek için çok küçük olduğunu bulabilirsiniz. Koleksiyon veritabanınıza en büyük tabloyu bakarak ihtiyacınız olacak alan miktarını tahmin etmek için tahminde bulundurabilirsiniz. DACPAC'ler aynı anda bir tablo oluşturulur. Nesli çalıştırmak için gereken maksimum alan gereksinimi kabaca koleksiyonun veritabanındaki en büyük tablonun boyutuna eşdeğerdir. Oluşturulan DACPAC'yi C sürücüsüne kaydediliyorsanız, doğrulama çalıştırması tarafından DataMigrationTool.log dosyasında bildirilen koleksiyon veritabanının boyutunu da dikkate alasınız.

DataMigrationTool.log dosyası, validate komutu her çalıştırılırken 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üde yer alan boş alanla karşılaştırın.

[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ünün en az o kadar fazla boş alana sahip olduğundan emin olun. Yoksa, bir ortam değişkeni ayarerek geçici dizini yeniden yönlendirmelisiniz.

SET TEMP={location on disk}

Bir diğer önemli nokta da DACPAC verisi kaydedilebilir. Kaydetme konumunu uzak bir uzak sürücüye işaret etmek çok daha uzun nesil sürelere neden olabilir. Katı hal sürücüsü (SSD) gibi bir hızlı sürücü yerel olarak kullanılabilirse, DACPAC kaydetme konumu olarak sürücüyü hedeflemenizi öneririz. Aksi takdirde, koleksiyon veritabanının bulunduğu makinede uzak sürücü yerine disk kullanmak her zaman daha hızlıdır.

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

Bir Komut İstemi penceresi açın ve SqlPackage.exe 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ğı:SQL Server veritabanınızı barındıran Azure DevOps Server örneğidir.
• İlk Katalog:Koleksiyon veritabanının adı.
• targetFile:Diskte 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.dacpacadlı koleksiyon veritabanı Foo'dan oluşturulan bir DACPAC dosyasıdır.

Koleksiyonunızı içeri aktarma için yapılandırma

Koleksiyon veritabanınız Azure VM'nize geri yüklendikten sonra, SQL içeri aktarması için Azure DevOps Services veritabanına bağlanmasına izin vermek üzere bir oturum açma kimliği oluşturun. Bu oturum açma, tek bir veritabanına yalnızca okuma erişimine izin verir.

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

Veritabanının kurtarmayı basit olarak ayarlayın:

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

Veritabanı için SQL oturum açma bilgileri oluşturun ve bu oturum açma bilgilerini 'TFSEXECROLE' olarak attayabilirsiniz:

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 komut aşağıdaki gibi olabilir:

ALTER DATABASE [Foo] SET RECOVERY SIMPLE;

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

vm'yi hedeflemek için içeri aktarma belirtimi dosyasını yapılandırma

İçeri aktarma belirtimi dosyasını, SQL Server örneğine bağlanma hakkında bilgi içerecek SQL Server güncelleştirin. İçeri aktarma belirtimi dosyanızı açın ve aşağıdaki güncelleştirmeleri yapın:

1. Kaynak dosyalar nesneden DACPAC parametresini kaldırın.

   Değişiklik öncesinde içeri aktarma belirtimi aşağıdaki kodda gösterilir:

   

   Değişiklik sonrasındaki içeri aktarma belirtimi aşağıdaki kodda gösterilmiştir:

   

2. Gerekli parametreleri doldurun ve aşağıdaki özellikler nesnesini kaynak nesnenizin içinde belirtim dosyasına 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" 
   }
   

Fabrikam örneğinde, değişiklikleri uygulayan içeri aktarma belirtimi aşağıdaki gibi olacaktır:

İçeri aktarma belirtimniz artık içeri aktarma için SQL Azure vm'yi kullanmak üzere yapılandırılmıştır. Geri kalan hazırlık adımlarıyla devam edin ve içeri aktarmayı Azure DevOps Services. İçeri aktarma işlemi tamam olduktan sonra oturum açma bilgilerini SQL veya parolayı döndürün. İçeri aktarma işlemi tamam olduktan sonra Microsoft oturum açma bilgilerini tutmaz.

3. Adım: DACPAC Upload dosyasını yeniden kaydedin

DACPAC'niz bir Azure depolama kapsayıcısı içine yerleştirilsin. Bu, mevcut bir kapsayıcı veya geçiş çabanız için özel olarak oluşturulmuş bir kapsayıcı olabilir. Kapsayıcınızı doğru bölgede oluşturduğunuzdan emin olmak önemlidir.

Azure DevOps Services birden çok bölgede kullanılabilir. Bu bölgelere içeri aktarma işleminizi tamamlarken, içeri aktarmanın başarıyla başlayamayabilir. Verileriniz, içeri aktaracakları bölgeye yerleştirilsin. Verilerin başka bir yere yerleştirilmesi, içeri aktarmanın başlatılamayarak sonuçlandır. Aşağıdaki tabloda depolama hesabınız oluşturmak ve verilerinizi karşıya yüklemek için kabul edilebilir bölgeler listelemektedir.

Bu Azure DevOps Services ABD'de birden çok bölgede kullanılabilir olsa da, yalnızca Orta Birleşik Devletler bölgesi yeni Azure DevOps Services. Şu anda verilerinizi diğer ABD Azure bölgelerine aktaraamayabilirsiniz.

Blob kapsayıcısı oluşturmak için Azure portal. Kapsayıcıyı oluşturduktan sonra Koleksiyon DACPAC dosyasını karşıya yükleyebilirsiniz.

İçeri aktarma işlemi tamam olduktan sonra blob kapsayıcıyı ve eşlik eden depolama hesabını silebilirsiniz. Bunu yapmak için AzCopy gibi araçları veya Azure Depolama Gezgini gibi başka bir Azure depolama gezgini aracını kullanabilirsiniz.

4. Adım: SAS anahtarı oluşturma

Paylaşılan erişim imzası (SAS) anahtarı, depolama hesabı içinde kaynaklara temsilci erişimi sağlar. Anahtar, microsoft'a içeri aktarmayı yürütmek için verilerinize erişmek için gereken en düşük ayrıcalık düzeyini vermenizi sağlar.

SAS anahtarı oluşturmanın önerilen yolu, Azure Depolama Gezgini. Bu Depolama Gezgini kapsayıcı düzeyinde SAS anahtarlarını kolayca oluşturabilirsiniz. Veri geçiş aracı hesap düzeyinde SAS anahtarlarını desteklemez.

Aşağıdaki adımları Depolama Gezgini sas anahtarı oluşturarak şunları yapabilirsiniz:

1. Depolama Gezgini'ni açın.

2. Hesap ekleyin.

3. Depolama hesabı adı ve anahtarı kullan'ı seçinve sonra da Depolama hesabı Bağlan.

   

4. Dış Erişim Ekle Depolama depolama hesabı adını girin, iki birincil erişim anahtarınızı girin ve sonra Dale'i Bağlan.

   

5. Sol bölmede Blob Kapsayıcıları'ni genişletin,içeri aktarma dosyalarınızı depolana kapsayıcıya sağ tıklayın ve Paylaşılan Erişim İmzası Al'ı seçin.

   

6. Sona erme zamanı için,sona erme tarihini gelecekteki yedi gün için ayarlayın.

   

7. SAS anahtarınız için izinler'in altında Oku ve Listeleonay kutularını seçin. Yazma ve silme izinleri gerekli değildir.

   Not

   • Sonraki adımda içeri aktarma belirtimi dosyanıza yer almak için bu SAS anahtarını kopyalayın ve depolayabilirsiniz.
   • Bu SAS anahtarını gizli anahtar olarak işle. Depolama kapsayıcısı içinde dosyalarınıza erişim sağlar.

5. Adım: İçeri aktarma belirtimlerini tamamlama

Daha önce, genellikle import.json olarak bilinen içeri aktarma belirtimi dosyasını kısmen doldurmıştınız. Bu noktada, içeri aktarma türü dışında kalan tüm alanları tamamlamak için yeterli bilgiye sahipsiniz. İçeri aktarma türü daha sonra içeri aktarma bölümünde ele alır.

import.json belirtim dosyasının Kaynakaltında aşağıdaki alanları doldurun:

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

Fabrikam örneğini kullanarak, içeri aktarma belirtimi dosyasının son örneği aşağıdaki gibi görünüyor olabilir:

Erişimi yalnızca Azure DevOps Services PS'lere kısıtlama

Azure Depolama hesabınıza erişimi yalnızca Azure DevOps Services. Bunu, yalnızca koleksiyon veritabanı içeri aktarma işlemiyle ilgili Azure DevOps Services kümeden gelen bağlantılara izin vererek yaparsınız. Depolama hesabınıza erişim verilmesi gereken IP'ler, içeri aktarmış bulunduğunuz bölgeye bağlıdır. Erişim verilmesi gereken IP'ler listesini almak için IpList seçeneğini kullanın.

Yardım belgelerine, veri örneği ve uzak makineden Migrator'Azure DevOps Server çalıştırmaya ilişkin yönergeler ve örnekler yer almaktadır. Azure DevOps Server örneğinin uygulama katmanlarından birini kullanarak komutunu çalıştırıyorsanız, komutunuz aşağıdaki yapıya sahip olması gerekir:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

İçeri aktarma türünü belirleme

İçeri aktarmalar bir kuru çalıştırma veya üretim çalıştırması olarak kuyruğa alınanlar olabilir. ImportType parametresi içeri aktarma türünü belirler:

• DryRun:Test amacıyla bir kuru çalıştırma kullanın. Sistem 21 gün sonra kuru çalıştırmaları siler.
• ProductionRun:Sonuçta elde edilen içeri aktarmayı tutmak ve içeri aktarma işlemi tamam olduktan sonra kuruluşun tam Azure DevOps Services bir üretim çalıştırması kullanın.

Kuru çalıştırma kuruluşları

İçeri aktarmaları kuru çalıştırma, ekiplerin koleksiyonlarının geçişini test sınasına yardımcı olur. Kuruluşların sonsuza kadar burada kalmaları değil kısa bir süre için var olması beklenir. Aslında, bir üretim geçişinin çalıştırılamayacak olması için tamamlanan tüm kuru çalıştırma kuruluşlarının silinmesi gerekir. Tüm kuru çalıştırma organizasyonlarının varlığı sınırlıdır ve belirli bir süre sonra otomatik olarak silinir. kuruluşun ne zaman silinip silinecekleri hakkında bilgiler, içeri aktarma işlemi tamam olduktan sonra alıca başarı e-postası içinde yer alır. Bu tarihi not edin ve uygun şekilde plan yapmayı unutmayın.

Çoğu kuru çalışma kuruluşlarının silinmeden önce 15 günü vardır. İçeri aktarma zamanında 100'den fazla kullanıcı temel veya daha fazla lisansa sahipse, kuru çalıştırma kuruluşları da 21 günlük süre sonuna sahip olabilir. Belirtilen sürenin ardından, kuru çalıştırma kuruluşu silinir. Üretim geçişi öncesinde içeri aktarmaları gereken sayıda tekrarlayın. Yeni bir çalıştırma denemeden önce önceki tüm kuru çalıştırmaları silmeniz gerekir. Takımınız bir üretim geçişi gerçekleştirmeye hazır olduğunda, kuru çalıştırma organizasyonlarını el ile silmeniz gerekir.

İçeri aktarma sonrası etkinlikler hakkında daha fazla bilgi için içeri aktarma sonrası makalesine bakın.

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

İçeri aktarma çalıştırma

Takımınız artık içeri aktarma işlemini çalıştırmaya hazır. Üretim çalıştırması içeri aktarmayı denemeden önce başarılı bir kuru çalıştırma içeri aktarma işlemiyle başlamayı öneririz. İçeri aktarmayı kuru çalıştırma ile üretim çalıştırmanıza başlamadan önce içeri aktarmanın nasıl bir görünüme sahip olduğunu görebilir, olası sorunları tanımlayabilir ve deneyim kazanabilirsiniz.

Geri alma planlarında dikkat edilmesi gerekenler

Son üretim çalıştırması yapan ekiplerin yaygın sorunlarından biri, içeri aktarmada bir sorun olursa geri alma planlarının ne olacağının olmasıdır. Bu nedenle, veri geçişi aracına, veri geçişi aracına sağ istediğiniz içeri aktarma ayarlarını test etmek için bir deneme Azure DevOps.

Son üretim çalıştırması için geri alma oldukça basittir. İçeri aktarmayı kuyruğa almadan önce takım projesi koleksiyonunu Azure DevOps Server veya Team Foundation Server ayırarak takım üyeleriniz tarafından kullanılamaz hale getirirsiniz. Herhangi bir nedenle üretim çalıştırmalarını geri almalı ve ekip üyeleriniz için şirket içi sunucuyu yeniden çevrimiçine getirebilirsiniz. Takım projesi koleksiyonunu şirket içinde yeniden iliştirin ve takımınızı olası hataları anlamak için yeniden gruplarken normal şekilde çalışmaya devam edecekleri konusunda bilgilendirin.

İçeri aktarma kuyruğu

Veri geçiş aracının içeri aktarma komutunu kullanarak içeri aktarmayı başlatabilirsiniz. İçeri aktarma komutu giriş olarak içeri aktarma belirtimi dosyasını alır. Sağlanan değerlerin geçerli olduğundan emin olmak için dosyayı ayrıştırır ve başarılı olursa içeri aktarmayı Azure DevOps Services. İçeri aktarma komutu için bir İnternet bağlantısı gerekir, ancak bu komut için Azure DevOps Server gerekli değildir.

Çalışmaya başlamanız için bir Komut İstemi penceresi açın ve dizinleri veri geçiş aracının yoluna göre değiştirebilirsiniz. Araçla birlikte sağlanan yardım metnini gözden geçirmek için biraz zaman geçirmenizi öneririz. İçeri aktarma komutuyla ilgili kılavuzu ve yardımı görmek için aşağıdaki komutu çalıştırın:

Migrator import /help

İçeri aktarmayı kuyruğa alma komutu aşağıdaki yapıya sahip olacak:

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

Tamamlanmış içeri aktarma komutunun bir örneği şöyledir:

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

Doğrulama başarılı olduktan sonra Azure AD'de oturum açmanız istener. Kimlik eşleme günlük dosyasıyla aynı Azure AD kiracısına üye olan bir kimlikle oturum açmak önemlidir. Oturum alan kullanıcı, içe aktarılan kuruluşun sahibi olur.

Takımınız içeri aktarmayı başlattığında, içeri aktarmayı kuyruğa alan kullanıcıya bir e-posta bildirimi gönderilir. İçeri aktarma kuyruğa alınana kadar yaklaşık 5-10 dakika sonra takımınız durumu kontrol etmek için kuruluşa gidebilir. İçeri aktarma işlemi tamam olduktan sonra takımınız oturum açma için yönlendirildi ve kuruluş sahibine bir e-posta bildirimi gönderilir.

İlgili makaleler:

• Geçiş seçenekleri
• İçeri aktarma sonrası