Share via

Melakukan migrasi uji coba

  • Artikel

Tim Anda sekarang siap untuk memulai proses memulai uji migrasi Anda dan akhirnya migrasi produksi penuh. Dalam fase ini, kita membahas langkah-langkah akhir untuk mengantrekan migrasi selain tugas lain yang biasanya muncul di akhir proyek migrasi.

Diagram menyoroti tahap Prasyarat dalam tahap berurutan.

Prasyarat

Selesaikan fase Siapkan uji coba sebelum Anda memulai migrasi uji coba.

Memvalidasi koleksi

Validasi setiap koleksi yang ingin Anda migrasikan ke Azure DevOps Services. Langkah validasi memeriksa berbagai aspek koleksi Anda, termasuk, tetapi tidak terbatas pada, ukuran, kolaksi, identitas, dan proses.

Jalankan validasi dengan menggunakan Alat Migrasi Data.

  1. Unduh Alat Migrasi Data.

  2. Salin file zip ke salah satu tingkat aplikasi Azure DevOps Server Anda.

  3. Ekstrak file. Anda juga dapat menjalankan alat dari komputer yang berbeda tanpa Azure DevOps Server terinstal, selama komputer dapat terhubung ke database konfigurasi instans Azure DevOps Server.

  4. Buka jendela Prompt Perintah di server, dan masukkan perintah cd untuk mengubah ke direktori tempat Alat Migrasi Data disimpan. Luangkan waktu beberapa saat untuk meninjau konten bantuan untuk alat ini.

    a. Untuk melihat bantuan dan panduan tingkat atas, jalankan perintah berikut.

     Migrator /help

    b. Lihat teks bantuan untuk perintah .

     Migrator validate /help

  5. Sebagai pertama kalinya Anda memvalidasi koleksi, perintah Anda harus memiliki struktur sederhana berikut.

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

    Di mana {name} menyediakan nama penyewa Microsoft Entra Anda, misalnya, untuk berjalan terhadap DefaultCollection dan penyewa fabrikam , perintah akan terlihat seperti contoh berikut.

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

  6. Untuk menjalankan alat dari komputer selain Azure DevOps Server, Anda memerlukan parameter /connectionString . Parameter string koneksi menunjuk ke database konfigurasi Azure DevOps Server Anda. Sebagai contoh, jika perintah yang divalidasi dijalankan oleh perusahaan Fabrikam, perintah akan terlihat seperti itu.

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

    Penting

    Alat Migrasi Data tidak mengedit data atau struktur apa pun dalam koleksi. Ini membaca koleksi hanya untuk mengidentifikasi masalah.

  7. Setelah validasi selesai, Anda dapat melihat file dan hasil log.

    Cuplikan layar hasil validasi dan log di jendela Prompt Perintah.

    Selama validasi, Anda menerima peringatan jika beberapa alur Anda berisi aturan retensi per alur. Azure DevOps Services menggunakan model retensi berbasis proyek dan tidak mendukung kebijakan retensi per alur. Jika Anda melanjutkan migrasi, kebijakan tidak dibawa ke versi yang dihosting. Sebagai gantinya, kebijakan retensi tingkat proyek default berlaku. Pertahankan build penting untuk Anda untuk menghindari kehilangannya.

Setelah semua validasi berlalu, Anda dapat pindah ke langkah berikutnya dari proses migrasi. Jika Alat Migrasi Data menandai kesalahan apa pun, koreksi sebelum Anda melanjutkan. Untuk panduan tentang memperbaiki kesalahan validasi, lihat Memecahkan masalah kesalahan migrasi dan migrasi.

Mengimpor file log

Saat membuka direktori log, Anda mungkin melihat beberapa file pengelogan.

File log utama diberi nama DataMigrationTool.log. Ini berisi detail tentang semua yang dijalankan. Untuk memudahkan Anda fokus pada area tertentu, log dihasilkan untuk setiap operasi validasi utama.

Misalnya, jika TfsMigrator melaporkan kesalahan dalam langkah "Memvalidasi Proses Proyek", Anda dapat membuka file ProjectProcessMap.log untuk melihat semua yang dijalankan untuk langkah tersebut alih-alih harus menggulir seluruh log.

Tinjau file TryMatchOobProcesses.log hanya jika Anda mencoba memigrasikan proses proyek Anda untuk menggunakan model yang diwariskan. Jika Anda tidak ingin menggunakan model yang diwariskan, Anda dapat mengabaikan kesalahan ini, karena tidak mencegah Anda mengimpor ke Layanan Azure DevOps. Untuk informasi selengkapnya, lihat Fase validasi migrasi.

Hasilkan file migrasi

Alat Migrasi Data memvalidasi pengumpulan dan mengembalikan hasil "Semua validasi koleksi lulus." Sebelum Anda mengambil koleksi offline untuk memigrasikannya, buat file migrasi. Saat menjalankan prepare perintah, Anda membuat dua file migrasi:

  • IdentityMapLog.csv: Menguraikan peta identitas Anda antara Direktori Aktif dan ID Microsoft Entra.
  • migration.json: Mengharuskan Anda mengisi spesifikasi migrasi yang ingin Anda gunakan untuk memulai migrasi Anda.

Perintah siapkan

prepare Perintah ini membantu menghasilkan file migrasi yang diperlukan. Pada dasarnya, perintah ini memindai koleksi untuk menemukan daftar semua pengguna untuk mengisi log peta identitas, IdentityMapLog.csv, lalu mencoba menyambungkan ke ID Microsoft Entra untuk menemukan kecocokan setiap identitas. Untuk melakukannya, perusahaan Anda perlu menggunakan alat Microsoft Entra Koneksi (sebelumnya dikenal sebagai alat Sinkronisasi Direktori, alat Sinkronisasi Direktori, atau alat DirSync.exe).

Jika sinkronisasi direktori disiapkan, Alat Migrasi Data harus menemukan identitas yang cocok dan menandainya sebagai Aktif. Jika tidak ada kecocokan, identitas ditandai sebagai Historis di log peta identitas, jadi Anda harus menyelidiki mengapa pengguna tidak disertakan dalam sinkronisasi direktori Anda. File spesifikasi migrasi, migration.json, harus diisi sebelum migrasi.

validate Tidak seperti perintah, preparememang memerlukan koneksi internet, karena perlu terhubung ke ID Microsoft Entra untuk mengisi file log peta identitas. Jika instans Azure DevOps Server Anda tidak memiliki akses internet, jalankan alat dari komputer yang melakukannya. Selama Anda dapat menemukan komputer dengan koneksi intranet ke instans Azure DevOps Server dan koneksi internet, Anda dapat menjalankan perintah ini. Untuk bantuan terkait prepare perintah, jalankan perintah berikut:

Migrator prepare /help

Disertakan dalam dokumentasi bantuan adalah instruksi dan contoh untuk menjalankan Migrator perintah dari instans Azure DevOps Server itu sendiri dan komputer jarak jauh. Jika Anda menjalankan perintah dari salah satu tingkat aplikasi instans Azure DevOps Server, perintah Anda harus memiliki struktur berikut:

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"

Parameter connectionString adalah penunjuk ke database konfigurasi instans Azure DevOps Server Anda. Sebagai contoh, jika perusahaan Fabrikam menjalankan prepare perintah, perintah terlihat seperti contoh berikut:

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

Saat Alat Migrasi Data menjalankan prepare perintah, Alat Migrasi menjalankan validasi lengkap untuk memastikan bahwa tidak ada yang berubah dengan koleksi Anda sejak validasi penuh terakhir. Jika ada masalah baru yang terdeteksi, tidak ada file migrasi yang dihasilkan.

Tak lama setelah perintah mulai berjalan, jendela masuk Microsoft Entra akan ditampilkan. Masuk dengan identitas milik domain penyewa, yang ditentukan dalam perintah. Pastikan bahwa penyewa Microsoft Entra yang ditentukan adalah penyewa yang Anda inginkan untuk didukung oleh organisasi di masa mendatang. Dalam contoh Fabrikam kami, pengguna memasukkan kredensial yang mirip dengan contoh cuplikan layar berikut.

Penting

Jangan gunakan penyewa Microsoft Entra pengujian untuk migrasi pengujian dan penyewa Microsoft Entra produksi Anda untuk eksekusi produksi. Menggunakan penyewa Microsoft Entra pengujian dapat mengakibatkan masalah migrasi identitas saat Anda memulai eksekusi produksi dengan penyewa Microsoft Entra produksi organisasi Anda.

Saat Anda berhasil menjalankan prepare perintah di Alat Migrasi Data, jendela hasil menampilkan sekumpulan log dan dua file migrasi. Di direktori log, temukan folder log dan dua file:

  • migration.json adalah file spesifikasi migrasi. Kami menyarankan agar Anda meluangkan waktu untuk mengisinya.
  • IdentityMapLog.csv berisi pemetaan Direktori Aktif yang dihasilkan ke identitas Microsoft Entra. Tinjau untuk kelengkapan sebelum Anda memulai migrasi.

Dua file dijelaskan secara lebih rinci di bagian berikutnya.

File spesifikasi migrasi

Spesifikasi migrasi, migration.json, adalah file JSON yang menyediakan pengaturan migrasi. Ini termasuk nama organisasi yang diinginkan, informasi akun penyimpanan, dan informasi lainnya. Sebagian besar bidang diisi otomatis, dan beberapa bidang memerlukan input Anda sebelum Anda mencoba migrasi.

Cuplikan layar file spesifikasi migrasi yang baru dibuat.

Bidang migration.json yang ditampilkan dan tindakan yang diperlukan dijelaskan dalam tabel berikut:

Bidang Deskripsi Tindakan yang diperlukan
Sumber Informasi tentang lokasi dan nama file data sumber yang digunakan untuk migrasi. Tidak diperlukan tindakan. Tinjau informasi untuk tindakan subbidang yang harus diikuti.
Lokasi Kunci tanda tangan akses bersama ke akun penyimpanan Azure yang menghosting paket aplikasi tingkat data (DACPAC). Tidak diperlukan tindakan. Bidang ini tercakup dalam langkah selanjutnya.
File Nama file yang berisi data migrasi. Tidak diperlukan tindakan. Tinjau informasi untuk tindakan subbidang yang harus diikuti.
DACPAC File DACPAC yang mengemas database koleksi yang akan digunakan untuk membawa data selama migrasi. Tidak diperlukan tindakan. Di langkah selanjutnya, Anda membuat file ini dengan menggunakan koleksi Anda lalu mengunggahnya ke akun penyimpanan Azure. Perbarui file berdasarkan nama yang Anda gunakan saat Anda membuatnya nanti dalam proses ini.
Target Properti organisasi baru untuk dimigrasikan. Tidak diperlukan tindakan. Tinjau informasi untuk tindakan subbidang yang harus diikuti.
Nama Nama organisasi yang akan dibuat selama migrasi. Berikan nama. Nama dapat dengan cepat diubah nanti setelah migrasi selesai.
CATATAN: Jangan membuat organisasi dengan nama ini sebelum Anda menjalankan migrasi. Organisasi dibuat sebagai bagian dari proses migrasi.
ImportType Jenis migrasi yang ingin Anda jalankan. Tidak diperlukan tindakan. Di langkah selanjutnya, pilih jenis migrasi yang akan dijalankan.
Data Validasi Informasi yang diperlukan untuk membantu mendorong pengalaman migrasi Anda. Alat Migrasi Data menghasilkan bagian "ValidationData". Ini berisi informasi untuk membantu mendorong pengalaman migrasi Anda. Jangan* edit nilai di bagian ini, atau migrasi Anda bisa gagal dimulai.

Setelah menyelesaikan proses sebelumnya, Anda harus memiliki file yang terlihat seperti contoh berikut.

Cuplikan layar file spesifikasi migrasi yang diselesaikan sebagian.

Pada gambar sebelumnya, perencana migrasi Fabrikam menambahkan nama organisasi fabrikam-import dan CUS yang dipilih (Central Amerika Serikat) sebagai lokasi geografis untuk migrasi. Nilai lain dibiarkan apa adanya untuk dimodifikasi tepat sebelum perencana mengambil koleksi offline untuk migrasi.

Catatan

Impor uji coba memiliki '-dryrun' yang secara otomatis ditambahkan ke akhir nama organisasi, yang dapat Anda ubah setelah migrasi.

Wilayah Azure yang didukung untuk migrasi

Layanan Azure DevOps tersedia di beberapa lokasi geografis Azure. Namun, tidak semua lokasi tempat Layanan Azure DevOps tersedia didukung untuk migrasi. Tabel berikut ini mencantumkan lokasi geografis Azure yang bisa Anda pilih untuk migrasi. Juga disertakan adalah nilai yang perlu Anda tempatkan dalam file spesifikasi migrasi untuk menargetkan geografi tersebut untuk migrasi.

Lokasi geografis Lokasi geografis Azure Nilai spesifikasi impor
Amerika Serikat Amerika Serikat Tengah CUS
Eropa Eropa Barat WEU
Inggris Raya Inggris Raya Selatan Inggris
Australia Australia Timur EAU
Amerika Selatan Brasil Selatan SBR
Asia Pasifik India Selatan MA
Asia Pasifik Asia Tenggara (Singapura) SEA
Kanada Kanada Tengah CC

Log peta identitas

Log peta identitas sama pentingnya dengan data aktual yang Anda migrasikan ke Azure DevOps Services. Saat Anda meninjau file, penting untuk memahami bagaimana migrasi identitas beroperasi dan apa yang mungkin diperlukan oleh hasil potensial. Saat Anda memigrasikan identitas, identitas tersebut dapat menjadi aktif atau historis. Identitas aktif dapat masuk ke Azure DevOps Services, tetapi identitas historis tidak dapat.

Identitas aktif

Identitas aktif mengacu pada identitas pengguna di Azure DevOps Services pascamigrasi. Di Azure DevOps Services, identitas ini dilisensikan dan ditampilkan sebagai pengguna di organisasi. Identitas ditandai sebagai aktif di kolom Status Impor yang Diharapkan dalam file log peta identitas.

Identitas historis

Identitas historis dipetakan seperti di kolom Status Impor yang Diharapkan dalam file log peta identitas. Identitas tanpa entri baris dalam file juga menjadi historis. Contoh identitas tanpa entri baris mungkin adalah karyawan yang tidak lagi bekerja di perusahaan.

Tidak seperti identitas aktif, identitas historis:

  • Tidak memiliki akses ke organisasi setelah migrasi.
  • Tidak memiliki lisensi.
  • Jangan muncul sebagai pengguna di organisasi. Semua yang berlanjut adalah gagasan nama identitas tersebut dalam organisasi, sehingga riwayatnya dapat dicari nanti. Kami menyarankan agar Anda menggunakan identitas historis untuk pengguna yang tidak lagi bekerja di perusahaan atau yang tidak memerlukan akses lebih lanjut ke organisasi.

Catatan

Setelah identitas diimpor sebagai historis, identitas tidak dapat menjadi aktif.

Memahami file log peta identitas

File log peta identitas mirip dengan contoh yang ditunjukkan di sini:

Cuplikan layar file log peta identitas yang dihasilkan oleh Alat Migrasi Data.

Kolom dalam file log peta identitas dijelaskan dalam tabel berikut:

Anda dan admin Microsoft Entra Anda harus menyelidiki pengguna yang ditandai sebagai Tidak Ditemukan Kecocokan (Periksa Sinkronisasi ID Microsoft Entra) untuk memahami mengapa mereka bukan bagian dari Microsoft Entra Koneksi Sync Anda.

Kolom Deskripsi
Direktori Aktif: Pengguna (Azure DevOps Server) Nama tampilan ramah yang digunakan oleh identitas di Azure DevOps Server. Nama ini memudahkan untuk mengidentifikasi pengguna mana yang dirujuk oleh garis dalam peta.
Direktori Aktif: Pengidentifikasi Keamanan Pengidentifikasi unik untuk identitas Active Directory lokal di Azure DevOps Server. Kolom ini digunakan untuk mengidentifikasi pengguna dalam koleksi.
ID Microsoft Entra: Pengguna Impor yang Diharapkan (Layanan Azure DevOps) Baik alamat masuk yang diharapkan dari pengguna yang cocok segera menjadi aktif atau Tidak Ditemukan Kecocokan (Periksa Sinkronisasi ID Microsoft Entra), yang menunjukkan bahwa identitas tersesat selama Sinkronisasi ID Microsoft Entra dan diimpor sebagai historis.
Status Impor yang Diharapkan Status migrasi pengguna yang diharapkan: Aktif jika ada kecocokan antara Direktori Aktif dan ID Microsoft Entra Anda, atau Historis jika tidak ada kecocokan.
Tanggal Validasi Terakhir kali log peta identitas divalidasi.

Saat Anda membaca file, perhatikan apakah nilai di kolom Status Impor yang Diharapkan aktifatau historis. Aktif menunjukkan bahwa identitas pada baris ini memetakan dengan benar pada migrasi menjadi aktif. Historis berarti bahwa identitas menjadi historis pada migrasi. Penting untuk meninjau file pemetaan yang dihasilkan untuk kelengkapan dan kebenaran.

Penting

Migrasi gagal jika perubahan besar terjadi pada sinkronisasi ID keamanan Microsoft Entra Koneksi antara upaya migrasi. Anda dapat menambahkan pengguna baru di antara uji coba, dan Anda dapat melakukan koreksi untuk memastikan bahwa identitas historis yang diimpor sebelumnya menjadi aktif. Namun, Anda tidak dapat mengubah pengguna yang sudah ada yang sebelumnya diimpor sebagai aktif. Melakukannya menyebabkan migrasi Anda gagal. Contoh perubahan mungkin menyelesaikan migrasi uji coba, menghapus identitas dari ID Microsoft Entra Anda yang diimpor secara aktif, membuat ulang pengguna baru di ID Microsoft Entra untuk identitas yang sama, lalu mencoba migrasi lain. Dalam hal ini, migrasi identitas aktif mencoba antara Direktori Aktif dan identitas Microsoft Entra yang baru dibuat, tetapi menyebabkan kegagalan migrasi.

  1. Tinjau identitas yang cocok dengan benar. Apakah semua identitas yang diharapkan ada? Apakah pengguna dipetakan ke identitas Microsoft Entra yang benar?

    Jika ada nilai yang harus diubah, hubungi administrator Microsoft Entra Anda untuk memverifikasi bahwa identitas Active Directory lokal adalah bagian dari sinkronisasi ke ID Microsoft Entra dan siapkan dengan benar. Untuk informasi selengkapnya, lihat Mengintegrasikan identitas lokal Anda dengan ID Microsoft Entra.

  2. Selanjutnya, tinjau identitas yang diberi label historis. Pelabelan ini menyiratkan bahwa identitas Microsoft Entra yang cocok tidak dapat ditemukan, karena salah satu alasan berikut:

    • Identitas tidak disiapkan untuk sinkronisasi antara Active Directory lokal dan ID Microsoft Entra.
    • Identitas belum diisi di ID Microsoft Entra Anda (misalnya, ada karyawan baru).
    • Identitas tidak ada di instans Microsoft Entra Anda.
    • Pengguna yang memiliki identitas tersebut tidak lagi bekerja di perusahaan.

Untuk mengatasi tiga alasan pertama, siapkan identitas Active Directory lokal yang dimaksudkan untuk disinkronkan dengan ID Microsoft Entra. Untuk informasi selengkapnya, lihat Mengintegrasikan identitas lokal Anda dengan ID Microsoft Entra. Anda harus menyiapkan dan menjalankan Microsoft Entra Koneksi agar identitas diimpor sebagai aktif di Azure DevOps Services.

Anda dapat mengabaikan alasan keempat, karena karyawan yang tidak lagi berada di perusahaan harus diimpor sebagai historis.

Identitas historis (tim kecil)

Catatan

Strategi migrasi identitas yang diusulkan di bagian ini harus dipertimbangkan oleh tim kecil saja.

Jika Microsoft Entra Koneksi tidak dikonfigurasi, semua pengguna dalam file log peta identitas ditandai sebagai historis. Menjalankan migrasi dengan cara ini menghasilkan semua pengguna diimpor sebagai historis. Kami sangat menyarankan Agar Anda mengonfigurasi Microsoft Entra Koneksi untuk memastikan bahwa pengguna Anda diimpor sebagai aktif.

Menjalankan migrasi dengan semua identitas historis memiliki konsekuensi yang perlu dipertimbangkan dengan hati-hati. Hanya tim dengan beberapa pengguna dan biaya pengaturan Microsoft Entra Koneksi yang dianggap terlalu tinggi yang harus dipertimbangkan.

Untuk memigrasikan semua identitas sebagai historis, ikuti langkah-langkah yang diuraikan di bagian selanjutnya. Saat Anda mengantrekan migrasi, identitas yang digunakan untuk mengantrekan migrasi di-bootstrap ke organisasi sebagai pemilik organisasi. Semua pengguna lain diimpor sebagai historis. Pemilik organisasi kemudian dapat menambahkan pengguna kembali dengan menggunakan identitas Microsoft Entra mereka. Pengguna yang ditambahkan diperlakukan sebagai pengguna baru. Mereka tidak memiliki riwayat apa pun, dan tidak ada cara untuk membandingkan kembali riwayat ini dengan identitas Microsoft Entra. Namun, pengguna masih dapat mencari riwayat pramigrasi mereka dengan mencari \<domain>\<Active Directory username>.

Alat Migrasi Data menampilkan peringatan jika mendeteksi skenario identitas historis lengkap. Jika Anda memutuskan untuk turun ke jalur migrasi ini, Anda perlu menyetujui alat untuk batasan.

Langganan Visual Studio

Alat Migrasi Data tidak dapat mendeteksi langganan Visual Studio (sebelumnya dikenal sebagai manfaat MSDN) saat menghasilkan file log peta identitas. Sebagai gantinya, kami sarankan Anda menerapkan fitur peningkatan lisensi otomatis setelah migrasi. Selama akun kerja pengguna ditautkan dengan benar, Azure DevOps Services secara otomatis menerapkan manfaat langganan Visual Studio mereka pada rincian masuk pertama mereka setelah migrasi. Anda tidak pernah dikenakan biaya untuk lisensi yang ditetapkan selama migrasi, sehingga Anda dapat menangani langganan dengan aman setelahnya.

Anda tidak perlu mengulangi migrasi uji coba jika langganan Visual Studio pengguna tidak ditingkatkan secara otomatis di Azure DevOps Services. Penautan langganan Visual Studio terjadi di luar lingkup migrasi. Selama akun kerja mereka ditautkan dengan benar sebelum atau sesudah migrasi, lisensi pengguna secara otomatis ditingkatkan pada rincian masuk berikutnya. Setelah lisensi mereka berhasil ditingkatkan, saat berikutnya Anda menjalankan migrasi, pengguna ditingkatkan secara otomatis pada masuk pertama mereka ke organisasi.

Penyiapan untuk migrasi

Sekarang Anda memiliki segala sesuatu yang siap untuk dijalankan pada migrasi uji coba Anda. Jadwalkan waktu henti dengan tim Anda untuk membuat koleksi offline untuk migrasi. Saat Anda menyetujui waktu untuk menjalankan migrasi, unggah aset yang diperlukan yang Anda buat dan salinan database ke Azure. Mempersiapkan migrasi terdiri dari lima langkah berikut.

Langkah 1: Ambil koleksi secara offline dan lepaskan. Langkah 2: Buat file DACPAC dari koleksi yang akan Anda migrasikan.
Langkah 3: Unggah file DACPAC dan file migrasi ke akun penyimpanan Azure.
Langkah 4: Buat token SAS untuk mengakses akun penyimpanan.
Langkah 5: Selesaikan spesifikasi migrasi.

Catatan

Sebelum Anda melakukan migrasi produksi, kami sangat menyarankan Anda menyelesaikan migrasi uji coba. Dengan uji coba, Anda dapat memvalidasi bahwa proses migrasi berfungsi untuk koleksi Anda dan bahwa tidak ada bentuk data unik yang mungkin menyebabkan kegagalan migrasi produksi.

Langkah 1: Lepaskan koleksi Anda

Melepaskan koleksi adalah langkah penting dalam proses migrasi. Data identitas untuk koleksi berada di database konfigurasi instans Azure DevOps Server saat koleksi dilampirkan dan online. Ketika koleksi dilepas dari instans Azure DevOps Server, dibutuhkan salinan data identitas tersebut dan mengemasnya dengan koleksi untuk transportasi. Tanpa data ini, bagian identitas migrasi tidak dapat dijalankan.

Tip

Kami menyarankan agar Anda tetap melepaskan koleksi hingga migrasi selesai, karena tidak ada cara untuk memigrasikan perubahan yang terjadi selama migrasi. Pasang kembali koleksi Anda setelah Anda mencadangkannya untuk migrasi, jadi Anda tidak khawatir memiliki data terbaru untuk jenis migrasi ini. Untuk menghindari waktu offline sama sekali, Anda juga dapat memilih untuk menggunakan pelampiran offline untuk uji coba.

Penting untuk menimbang biaya memilih untuk menimbulkan waktu henti nol untuk uji coba. Ini memerlukan pengambilan cadangan database koleksi dan konfigurasi, memulihkannya pada instans SQL, lalu membuat cadangan yang dilepaskan. Analisis biaya dapat membuktikan bahwa hanya membutuhkan beberapa jam waktu henti untuk langsung mengambil cadangan yang terlepas lebih baik pada akhirnya.

Langkah 2: Membuat file DACPAC

DACPAC menawarkan metode yang cepat dan relatif mudah untuk memindahkan koleksi ke Azure DevOps Services. Namun, setelah ukuran database koleksi melebihi ambang batas tertentu, manfaat menggunakan DACPAC mulai berkurang.

Catatan

Jika Alat Migrasi Data menampilkan peringatan bahwa Anda tidak dapat menggunakan metode DACPAC, Anda harus melakukan migrasi dengan menggunakan metode komputer virtual (VM) SQL Azure. Lewati langkah 2 hingga 5 dalam hal ini dan ikuti instruksi dalam fase Siapkan uji coba, Migrasikan koleksi besar, lalu lanjutkan untuk menentukan jenis migrasi. Jika Alat Migrasi Data tidak menampilkan peringatan, gunakan metode DACPAC yang dijelaskan dalam langkah ini.

DACPAC adalah fitur SQL Server yang memungkinkan database dikemas ke dalam satu file dan disebarkan ke instans SQL Server lainnya. File DACPAC juga dapat dipulihkan langsung ke Azure DevOps Services, sehingga Anda dapat menggunakannya sebagai metode pengemasan untuk mendapatkan data koleksi Anda di cloud.

Penting

  • Saat menggunakan SqlPackage.exe, Anda harus menggunakan versi .NET Framework SqlPackage.exe untuk menyiapkan DACPAC. Penginstal MSI harus digunakan untuk menginstal versi .NET Framework dari SqlPackage.exe. Jangan gunakan versi dotnet CLI atau .zip (Windows .NET 6) SqlPackage.exe karena versi tersebut dapat menghasilkan DACPAC yang tidak kompatibel dengan Azure DevOps Services.
  • SqlPackage versi 161 mengenkripsi koneksi database secara default dan mungkin tidak tersambung. Jika Anda menerima kesalahan proses masuk, tambahkan ;Encrypt=False;TrustServerCertificate=True ke string koneksi pernyataan SqlPackage.

Unduh dan instal SqlPackage.exe menggunakan Penginstal MSI terbaru dari catatan rilis SqlPackage.

Setelah Anda menggunakan Penginstal MSI, SqlPackage.exe menginstal di jalur yang mirip %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\dengan .

Saat Anda membuat DACPAC, ingatlah dua pertimbangan: disk tempat DACPAC disimpan dan ruang disk pada komputer yang menghasilkan DACPAC. Anda ingin memastikan bahwa Anda memiliki cukup ruang disk untuk menyelesaikan operasi.

Saat membuat paket, SqlPackage.exe untuk sementara menyimpan data dari koleksi Anda di direktori sementara pada drive C mesin tempat Anda memulai permintaan pengemasan.

Anda mungkin menemukan bahwa drive C Anda terlalu kecil untuk mendukung pembuatan DACPAC. Anda dapat memperkirakan jumlah ruang yang Anda butuhkan dengan mencari tabel terbesar dalam database koleksi Anda. DACPAC dibuat satu tabel pada satu waktu. Persyaratan ruang maksimum untuk menjalankan pembuatan kira-kira setara dengan ukuran tabel terbesar dalam database koleksi. Jika Anda menyimpan DACPAC yang dihasilkan untuk mendorong C, pertimbangkan ukuran database koleksi seperti yang dilaporkan dalam file DataMigrationTool.log dari eksekusi validasi.

File DataMigrationTool.log menyediakan daftar tabel terbesar dalam koleksi setiap kali perintah dijalankan. Untuk contoh ukuran tabel untuk koleksi, lihat output berikut. Bandingkan ukuran tabel terbesar dengan ruang kosong pada drive yang menghosting direktori sementara Anda.

Penting

Sebelum Anda melanjutkan pembuatan file DACPAC, pastikan koleksi Anda dilepaskan.

[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

Pastikan bahwa drive yang menghosting direktori sementara Anda memiliki setidaknya ruang kosong sebanyak mungkin. Jika tidak, Anda perlu mengalihkan direktori sementara dengan mengatur variabel lingkungan.

SET TEMP={location on disk}

Pertimbangan lain adalah tempat data DACPAC disimpan. Mengarahkan lokasi yang disimpan ke drive jarak jauh dapat mengakibatkan waktu pembuatan yang lebih lama. Jika drive cepat seperti solid-state drive (SSD) tersedia secara lokal, kami sarankan Anda menargetkan drive sebagai lokasi penyimpanan DACPAC. Jika tidak, selalu lebih cepat untuk menggunakan disk yang ada di komputer tempat database koleksi berada daripada drive jarak jauh.

Sekarang setelah Anda mengidentifikasi lokasi target untuk DACPAC dan memastikan bahwa Anda memiliki cukup ruang, saatnya untuk menghasilkan file DACPAC.

Buka jendela Prompt Perintah dan buka lokasi SqlPackage.exe. Untuk menghasilkan DACPAC, ganti nilai tempat penampung dengan nilai yang diperlukan, lalu jalankan perintah berikut:

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
  • Sumber Data: Instans SQL Server yang menghosting database koleksi Azure DevOps Server Anda.
  • Katalog Awal: Nama database koleksi.
  • targetFile: Lokasi pada disk dan nama file DACPAC.

Perintah pembuatan DACPAC yang berjalan di tingkat data Azure DevOps Server itu sendiri diperlihatkan dalam contoh berikut:

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

Output perintah adalah file DACPAC, yang dihasilkan dari database koleksi Foo yang disebut Foo.dacpac.

Mengonfigurasi koleksi Anda untuk migrasi

Setelah database koleksi Anda dipulihkan di Azure VM Anda, konfigurasikan masuk SQL untuk memungkinkan Azure DevOps Services tersambung ke database untuk memigrasikan data. Rincian masuk ini hanya memungkinkan akses baca ke satu database.

Untuk memulai, buka SQL Server Management Studio pada VM, lalu buka jendela kueri baru terhadap database yang akan diimpor.

Atur pemulihan database menjadi sederhana:

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

Buat rincian masuk SQL untuk database, dan tetapkan rincian masuk tersebut 'TFSEXECROLE':

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>'

Mengikuti contoh Fabrikam kami, dua perintah SQL akan terlihat seperti contoh berikut:

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'

Catatan

Aktifkan mode autentikasi SQL Server dan Windows di SQL Server Management Studio pada VM. Jika Anda tidak mengaktifkan mode autentikasi, migrasi gagal.

Mengonfigurasi file spesifikasi migrasi untuk menargetkan VM

Perbarui file spesifikasi migrasi untuk menyertakan informasi tentang cara menyambungkan ke instans SQL Server. Buka file spesifikasi migrasi Anda dan buat pembaruan berikut.

  1. Hapus parameter DACPAC dari objek file sumber.

    Spesifikasi migrasi sebelum perubahan ditampilkan dalam kode berikut.

    Cuplikan layar spesifikasi migrasi sebelum perubahan.

    Spesifikasi migrasi setelah perubahan ditampilkan dalam kode berikut.

    Cuplikan layar spesifikasi migrasi setelah perubahan.

  2. Isi parameter yang diperlukan dan tambahkan objek properti berikut dalam objek sumber Anda dalam file spesifikasi.

    "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" 
}

Setelah Anda menerapkan perubahan, spesifikasi migrasi terlihat seperti contoh berikut.

Cuplikan layar spesifikasi migrasi yang mereferensikan SQL Azure VM.

Spesifikasi migrasi Anda sekarang dikonfigurasi untuk menggunakan SQL Azure VM untuk migrasi. Lanjutkan dengan langkah-langkah persiapan lainnya untuk migrasi ke Azure DevOps Services. Setelah migrasi selesai, pastikan untuk menghapus masuk SQL atau memutar kata sandi. Microsoft tidak menyimpan informasi masuk setelah migrasi selesai.

Langkah 3: Unggah file DACPAC

Catatan

Jika Anda menggunakan metode SQL Azure VM, Anda hanya perlu menyediakan string koneksi. Anda tidak perlu mengunggah file apa pun, dan Anda dapat melewati langkah ini.

DACPAC Anda harus ditempatkan dalam kontainer penyimpanan Azure, yang dapat menjadi kontainer yang sudah ada atau yang dibuat khusus untuk upaya migrasi Anda. Penting untuk memastikan bahwa kontainer Anda dibuat di lokasi geografis yang tepat.

Layanan Azure DevOps tersedia di beberapa lokasi geografis. Saat Anda mengimpor ke lokasi ini, sangat penting untuk menempatkan data Anda dengan benar untuk memastikan bahwa migrasi dapat dimulai dengan sukses. Data Anda harus ditempatkan di lokasi geografis yang sama dengan yang Anda impor. Menempatkan data di tempat lain menyebabkan migrasi tidak dapat dimulai. Tabel berikut mencantumkan lokasi geografis yang dapat diterima untuk membuat akun penyimpanan Anda dan mengunggah data Anda.

Lokasi geografis migrasi yang diinginkan Lokasi geografis akun penyimpanan
Amerika Serikat Tengah Amerika Serikat Tengah
Eropa Barat Eropa Barat
Inggris Raya Inggris Raya Selatan
Australia Timur Australia Timur
Brasil Selatan Brasil Selatan
India Selatan India Selatan
Kanada Tengah Kanada Tengah
Asia Pasifik (Singapura) Asia Pasifik (Singapura)

Meskipun Layanan Azure DevOps tersedia di beberapa lokasi geografis di AS, hanya lokasi Amerika Serikat Pusat yang menerima Layanan Azure DevOps baru. Anda tidak dapat memigrasikan data Anda ke lokasi Azure AS lainnya saat ini.

Buat kontainer blob dari portal Azure. Setelah Anda membuat kontainer, unggah file DACPAC Koleksi.

Setelah migrasi selesai, hapus kontainer blob dan akun penyimpanan yang menyertai alat seperti AzCopy atau alat penjelajah penyimpanan Azure lainnya, seperti Azure Storage Explorer.

Catatan

Jika file DACPAC Anda lebih besar dari 10 GB, kami sarankan Anda menggunakan AzCopy. AzCopy memiliki dukungan unggahan multithreaded untuk unggahan yang lebih cepat.

Langkah 4: Hasilkan token SAS

Token tanda tangan akses bersama (SAS) menyediakan akses yang didelegasikan ke sumber daya di akun penyimpanan. Token ini memungkinkan Anda untuk memberi Microsoft tingkat hak istimewa terendah yang diperlukan untuk mengakses data Anda untuk menjalankan migrasi.

Anda dapat menghasilkan token SAS menggunakan portal Azure. Dari sudut pandang keamanan, sebaiknya lakukan tugas berikut:

  1. Pilih hanya Baca dan Daftar sebagai izin untuk token SAS Anda. Tidak diperlukan izin lain.
  2. Tetapkan waktu kedaluwarsa tidak lebih dari tujuh hari ke depan.
  3. Batasi akses ke IP Azure DevOps Services saja.
  4. Perlakukan kunci SAS sebagai rahasia. Jangan tinggalkan kunci di lokasi yang tidak aman karena memberikan akses baca dan daftar ke data apa pun yang telah Anda simpan dalam kontainer.

Langkah 5: Selesaikan spesifikasi migrasi

Sebelumnya dalam proses Anda mengisi sebagian file spesifikasi migrasi, yang dikenal sebagai migration.json. Pada titik ini, Anda memiliki informasi yang cukup untuk menyelesaikan semua bidang yang tersisa kecuali untuk jenis migrasi. Jenis migrasi tercakup nanti, di bagian migrasi.

Dalam file spesifikasi migration.json, di bawah Sumber, selesaikan bidang berikut ini.

  • Lokasi: Tempelkan kunci SAS yang Anda buat dari skrip lalu salin di langkah sebelumnya.
  • Dacpac: Pastikan bahwa file, termasuk ekstensi file .dacpac , memiliki nama yang sama dengan file DACPAC yang Anda unggah ke akun penyimpanan.

File spesifikasi migrasi akhir akan terlihat seperti contoh berikut.

Cuplikan layar file spesifikasi migrasi yang telah selesai.

Menentukan jenis migrasi

Impor dapat diantrekan sebagai uji coba atau eksekusi produksi. Parameter ImportType menentukan jenis migrasi:

  • TestRun: Gunakan uji coba untuk tujuan pengujian. Sistem menghapus eksekusi pengujian setelah 45 hari.
  • ProductionRun: Gunakan eksekusi produksi saat Anda ingin menyimpan migrasi yang dihasilkan dan menggunakan organisasi penuh waktu di Azure DevOps Services setelah migrasi selesai.

Tip

Kami selalu menyarankan agar Anda menyelesaikan migrasi uji coba terlebih dahulu.

Cuplikan layar file spesifikasi migrasi yang telah selesai dengan jenis migrasi.

Menguji organisasi yang dijalankan

Organisasi uji coba membantu tim menguji migrasi koleksi mereka. Sebelum migrasi produksi dapat dijalankan, organisasi eksekusi pengujian yang telah selesai harus dihapus. Semua organisasi uji coba memiliki keberadaan terbatas dan secara otomatis dihapus setelah periode waktu yang ditetapkan. Informasi tentang kapan organisasi dihapus disertakan dalam email keberhasilan yang harus Anda terima setelah migrasi selesai. Pastikan untuk mencatat tanggal dan rencana ini yang sesuai.

Organisasi uji coba memiliki waktu 45 hari sebelum dihapus. Setelah periode waktu yang ditentukan, organisasi uji coba dihapus. Anda dapat mengulangi impor uji coba sebanyak yang Anda butuhkan sebelum melakukan migrasi produksi.

Menghapus eksekusi pengujian

Hapus eksekusi pengujian sebelumnya sebelum Anda mencoba yang baru. Saat tim Anda siap untuk melakukan migrasi produksi, Anda perlu menghapus organisasi uji coba secara manual. Sebelum Anda dapat menjalankan migrasi uji coba kedua atau migrasi produksi akhir, pastikan Anda menghapus organisasi Azure DevOps Services sebelumnya yang Anda buat dalam eksekusi pengujian sebelumnya. Untuk informasi selengkapnya, lihat Menghapus organisasi.

Tip

Informasi opsional untuk membantu pengguna menjadi lebih suksesMenjalankan migrasi uji coba yang mengikuti yang pertama diharapkan memakan waktu lebih lama mengingat waktu tambahan yang diperlukan untuk membersihkan sumber daya dari eksekusi pengujian sebelumnya.

Diperlukan waktu hingga satu jam agar nama organisasi tersedia setelah menghapus atau mengganti nama. Untuk informasi selengkapnya, lihat artikel Tugas pascamigrasi .

Jika Anda mengalami masalah migrasi, lihat Memecahkan masalah kesalahan migrasi dan migrasi.

Menjalankan migrasi

Tim Anda sekarang siap untuk memulai proses menjalankan migrasi. Kami menyarankan agar Anda memulai dengan migrasi uji coba yang berhasil sebelum mencoba migrasi yang dijalankan produksi. Dengan impor uji coba, Anda dapat melihat terlebih dahulu bagaimana migrasi terlihat, mengidentifikasi potensi masalah, dan mendapatkan pengalaman sebelum Anda masuk ke eksekusi produksi Anda.

Catatan

  • Jika Anda perlu mengulangi migrasi eksekusi produksi yang telah selesai untuk koleksi, seperti saat pemutaran kembali, hubungi Dukungan Pelanggan Azure DevOps Services sebelum Anda mengantrekan migrasi lain.
  • Administrator Azure dapat mencegah pengguna membuat organisasi Azure DevOps baru. Jika kebijakan penyewa Microsoft Entra diaktifkan, migrasi Anda gagal diselesaikan. Sebelum memulai, verifikasi bahwa kebijakan tidak ditetapkan atau ada pengecualian untuk pengguna yang melakukan migrasi. Untuk informasi selengkapnya, lihat Membatasi pembuatan organisasi melalui kebijakan penyewa Microsoft Entra.
  • Azure DevOps Services tidak mendukung kebijakan retensi per alur, dan tidak dibawa ke versi yang dihosting.

Pertimbangan untuk rencana pembatalan

Kekhawatiran umum bagi tim yang melakukan eksekusi produksi akhir adalah rencana putar kembali mereka, jika ada yang salah dengan migrasi. Sebaiknya lakukan uji coba untuk memastikan bahwa Anda dapat menguji pengaturan migrasi yang Anda berikan ke Alat Migrasi Data untuk Azure DevOps.

Putar kembali untuk eksekusi produksi akhir cukup sederhana. Sebelum Anda mengantre migrasi, lepaskan koleksi proyek tim dari Azure DevOps Server, yang membuatnya tidak tersedia untuk anggota tim Anda. Jika karena alasan apa pun Anda perlu mengembalikan eksekusi produksi dan membawa server lokal kembali online untuk anggota tim Anda, Anda dapat melakukannya. Lampirkan pengumpulan proyek tim secara lokal lagi dan beri tahu tim Anda bahwa mereka terus bekerja secara normal saat tim Anda mengumpulkan kembali untuk memahami potensi kegagalan.

Anda kemudian dapat menghubungi dukungan pelanggan Azure DevOps Services untuk bantuan dalam memahami penyebab kegagalan jika Anda tidak dapat menentukan penyebabnya. Untuk informasi selengkapnya, lihat artikel Pemecahan Masalah. Tiket dukungan pelanggan dapat dibuka dari halaman https://aka.ms/AzureDevOpsImportSupportberikut. Penting untuk dicatat bahwa jika masalah mengharuskan teknisi grup produk untuk melibatkan kasus tersebut akan ditangani selama jam kerja reguler.

Lepaskan koleksi proyek tim Anda dari Azure DevOps Server untuk menyiapkannya untuk migrasi.

Sebelum membuat cadangan database SQL Anda, Alat Migrasi Data mengharuskan koleksi sepenuhnya terlepas dari Azure DevOps Server (bukan SQL). Proses penghapusan di Azure DevOps Server mentransfer informasi identitas pengguna yang disimpan di luar database koleksi dan membuatnya portabel untuk pindah ke server TFS baru atau dalam hal ini, ke Azure DevOps Services.

Melepaskan koleksi mudah dilakukan dari Konsol Administrasi Azure DevOps Server pada instans Azure DevOps Server Anda. Untuk informasi selengkapnya, lihat Memindahkan koleksi proyek, Melepaskan koleksi.

Mengantrekan migrasi

Penting

Sebelum melanjutkan, pastikan koleksi Anda dilepas sebelum membuat file DACPAC atau mengunggah database koleksi ke SQL Azure VM. Jika Anda tidak menyelesaikan langkah ini, migrasi gagal. Jika migrasi Anda gagal, lihat Mengatasi kesalahan migrasi.

Mulai migrasi dengan menggunakan perintah impor Alat Migrasi Data. Perintah migrasi mengambil file spesifikasi migrasi sebagai input. Ini menguraikan file untuk memastikan bahwa nilai yang disediakan valid dan, jika berhasil, ia mengantrekan migrasi ke Azure DevOps Services. Perintah migrasi memerlukan koneksi internet, tetapi tidak* memerlukan koneksi ke instans Azure DevOps Server Anda.

Untuk memulai, buka jendela Prompt Perintah, dan ubah direktori ke jalur ke Alat Migrasi Data. Kami menyarankan agar Anda meninjau teks bantuan yang disediakan dengan alat ini. Jalankan perintah berikut untuk melihat panduan dan bantuan untuk perintah migrasi:

Migrator migration /help

Perintah untuk mengantrekan migrasi memiliki struktur berikut:

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

Contoh berikut menunjukkan perintah migrasi yang telah selesai:

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

Setelah validasi lolos, masuk ke MICROSOFT Entra ID dengan identitas yang merupakan anggota penyewa Microsoft Entra yang sama dengan file log peta identitas yang dibangun. Pengguna yang masuk adalah pemilik organisasi yang diimpor.

Catatan

Setiap penyewa Microsoft Entra dibatasi hingga lima impor per periode 24 jam. Hanya impor yang dihitung dalam antrean terhadap batas ini.

Saat tim Anda memulai migrasi, pemberitahuan email dikirim ke pengguna yang mengantrekan migrasi. Sekitar 5 hingga 10 menit setelah antrean migrasi, tim Anda dapat masuk ke organisasi untuk memeriksa status. Setelah migrasi selesai, tim Anda diarahkan untuk masuk, dan pemberitahuan email dikirim ke pemilik organisasi.

Alat Migrasi Data menandai kesalahan yang perlu Anda koreksi sebelum migrasi. Artikel ini menjelaskan peringatan dan kesalahan paling umum yang mungkin Anda terima saat bersiap untuk bermigrasi. Setelah Anda memperbaiki setiap kesalahan, jalankan perintah validasi migrator lagi untuk memverifikasi resolusi.

Langkah berikutnya

Mengatasi kesalahan migrasi