Share via


Geçiş işlemine genel bakış

Azure DevOps Server'dan Azure DevOps Services'e geçmek, bulut tabanlı işbirliği, ölçeklenebilirlik ve gelişmiş özelliklerden yararlanmak isteyen kuruluşlar için önemli bir adımdır. Bu genel bakışta, değerli verilerinizi şirket içi Azure DevOps Server'dan bulut tabanlı Azure DevOps Services'e aktarma seçeneklerini inceleyeceğiz.

Şirket içi Azure DevOps Sunucusu ile bulut tabanlı Azure DevOps Services arasındaki temel farklar hakkında bilgi için bkz . Azure DevOps Services ile Azure DevOps Server - Azure DevOps karşılaştırması.

Seçtiğiniz geçiş seçeneğinden bağımsız olarak, kaynak kodu ve iş öğeleri gibi en önemli varlıklarınızı belirlemenizi öneririz. Veri boyutunuzu, kuruluş karmaşıklığınızı düşünmeli ve sorunsuz ve başarılı bir geçiş için gerçek geçiş öncesinde test çalıştırmaları için yeterli zamanınız olduğundan emin olmalısınız.

Geçiş yaklaşımları

Azure DevOps Services'i benimsemeye yönelik motivasyonlarınıza bağlı olarak geçişe yönelik her yaklaşımın olumlu ve dezavantajlarını değerlendirmek çok önemlidir. Doğru strateji, benzersiz bağlamınıza ve gereksinimlerinize bağlıdır.

Seçenekler Önerilen senaryolar Sınırlamalar
1: El ile geçiş Daha küçük projeler veya belirli veri alt kümeleri için kullanın. Tüm veriler tam uygunlukla geçirilebilir ve azaltmaya tabi değildir. Bu geçiş XML şablonlarının geçirilmesini desteklemediğinden, işlem şablonlarını devralınan şablonlar olarak yeniden oluşturmanız gerekir.
2: Azure DevOps Veri Geçiş Aracı Çeşitli veri türleri ve karmaşık yapılara sahip orta ve büyük ölçekli geçişler için kullanın. Değişiklik yapmadan yalnızca bir Azure DevOps Server koleksiyonunu yeni bir Azure DevOps Services kuruluşuna "kaldırabilir ve kaydırabilirsiniz". Daha fazla bilgi için Sınırlamalar bölümüne bakın.
3: API tabanlı geçiş Benzersiz geçiş gereksinimleri veya otomasyon gereksinimleri olan kuruluşlar için esneklik ve özelleştirme sunar. Düşük uygunluk, veri kaybı ve kimlik değişiklikleri oluşabilir. Daha fazla bilgi için Sınırlamalar bölümüne bakın.

1. Seçenek: El ile geçiş

Örneğin, Microsoft'taki Azure DevOps ekibi Azure DevOps Server'dan Azure DevOps Services'a geçmeyi seçtiğinde, Team Foundation Sürüm Denetimi 'den (TFVC) Git'e geçmeye de karar verdik. Geçiş için çok fazla planlama gerekiyordu, ancak geçiş yaptığımızda TFVC kaynaklarımızın "ipucu" sürümünü kullanarak yeni bir Git deposu oluşturduk ve geçmişimizi Azure DevOps Server'da geride bıraktık. Ayrıca etkin iş öğelerimizi taşıdık ve tüm eski hatalarımızı, tamamlanmış kullanıcı hikayelerimizi ve görevlerimizi vb. geride bıraktık.

El ile geçiş işlemi

  1. Geçirmeniz gereken en önemli varlıkları (genellikle kaynak kodu, iş öğeleri veya her ikisi) tanımlayın. Azure DevOps Server'daki diğer varlıkların (derleme işlem hatları, test planları vb.) el ile geçirilmesi zordur.
  2. Geçişi yapmak için uygun bir zaman belirleyin.
  3. Hedef organizasyonlarınızı hazırlayın. İhtiyacınız olan kuruluşları ve ekip projelerini oluşturun, kullanıcıları sağlayın vb.
  4. Verilerinizi geçirin.
  5. Kaynak Azure DevOps Server dağıtımlarını salt okunur hale getirebilirsiniz. Bunu aşağıdaki yollarla yapabilirsiniz:
    • Proje düzeyi izinlerini ayarlama: Tüm kullanıcıların veya grupların izinlerini proje düzeyinde salt okunur olarak ayarlayın; bunu Project ayarlarında güvenlik rollerini değiştirerek yapabilirsiniz.
    • Depo ayarlarını değiştirme: Her depo için, her kullanıcı veya grubun izinlerini yalnızca okuma eylemlerine izin verecek şekilde ayarlamayı içeren ayarları salt okunur hale getirmek üzere değiştirebilirsiniz.
    • Yerleşik güvenlik gruplarını kullanma: İzinleri daha verimli bir şekilde yönetmek için yerleşik güvenlik gruplarını kullanın. Salt okunur erişim sağlamak için kullanıcıları "Okuyucular" gibi gruplara atayabilirsiniz.
    • Betik oluşturma izni değişiklikleri: Çok sayıda projeniz veya deponuz varsa bunları betik olarak yazmanız gerekebilir. Azure CLI DevOps uzantısını kullanarak tüm izinleri listeleyebilir ve gerektiğinde güncelleştirebilirsiniz.
    • Depoyu devre dışı bırakma özelliği: Derlemeler ve çekme istekleri dahil olmak üzere depoya erişimi devre dışı bırakır, ancak depoyu bir uyarıyla bulunabilir durumda tutar. Proje ayarları>> Deponuzu depolar'a gidin ve Depoyu Devre Dışı Bırak'ın yanındaki iki durumlu düğmeyi Açık konuma getirin.

2. Seçenek: Azure DevOps Geçiş Aracı

Azure DevOps Veri Geçiş Aracı, Azure DevOps Server'dan Azure DevOps Services'a veri geçişini kolaylaştırmak için Microsoft tarafından sağlanan bir dizi yardımcı programdır. Bu araçlar kaynak kodu, iş öğeleri, test çalışmaları ve projeyle ilgili diğer veriler dahil olmak üzere çeşitli yapıtları geçirmek için kolaylaştırılmış bir yaklaşım sunar.

Geçiş işlemini başlatmadan önce, araçlar kaynak ortamın hazır olma durumunu değerlendirmek ve geçişi etkileyebilecek olası sorunları veya bağımlılıkları belirlemek için bir geçiş öncesi analizi gerçekleştirebilir. Olası zorlukları önceden planlayıp azaltabilmeniz için hazır olma durumunu değerlendirin.

Geçiş Aracı sınırlamaları

Araç, aşağıdaki nedenlerle hiçbir değişiklik yapmadan bir Azure DevOps Server Koleksiyonunu yeni bir Azure DevOps Service Kuruluşuna "kaldırmanıza ve kaydırmanıza" olanak tanır:

  • Veri bütünlüğü ve tutarlılığı:
    • Verileri geçirirken bütünlüğü ve tutarlılığı korumak çok önemlidir. Geçiş sırasında değişikliklere izin vermek veri bozulmasına veya tutarsızlıklara neden olabilir.
    • Araç, aktarım işlemi sırasında verilerin bozulmadan kalmasını sağlayarak hata riskini en aza indirir.
  • Kaynak veri koruma:
    • Geçiş aracı, kaynak verileri hedef ortamda sadık bir şekilde çoğaltmayı amaçlar.
    • Değişiklikler özgün verileri değiştirerek geçirilen verilerle kaynak veriler arasında tutarsızlıklara neden olabilir.
  • Tahmin edilebilir davranış:
    • Araç, değişiklikleri kısıtlayarak geçiş sırasında öngörülebilir davranışlar sağlar.
    • Kullanıcılar beklenmeyen değişiklikler olmadan tutarlı sonuçlara güvenebilir.
  • Geçiş odağı, dönüştürme değil:
    • Geçiş aracının birincil amacı, verileri bir konumdan diğerine taşımaktır.
    • Veri dönüştürme (değerleri değiştirme gibi) genellikle geçiş sonrasında ayrı olarak işlenir.

Geçiş öncesinde veya sonrasında ihtiyacınız olmayan verileri temizleyebilirsiniz.

Geçiş Aracı işlemi

  1. Azure DevOps Server'ı en son iki sürümden birine güncelleştirme gibi önkoşulları tamamlayın.
  2. Azure DevOps Services'a taşımak istediğiniz her koleksiyonu doğrulayın.
  3. Geçiş dosyaları oluşturma.
  4. Geçiş yürütmeniz için her şeyi hazırlayın.
  5. Bir test çalıştırması gerçekleştirin.
  6. Geçişi gerçekleştirin.
  7. Kullanıcılarınızın ve verilerinizin geçirildiğini ve koleksiyonun beklendiği gibi çalıştığını onaylayın.

3. Seçenek: API tabanlı geçiş

Bazı nedenlerden dolayı Veri Geçiş Aracı'nı kullanamıyor ancak yine de Seçenek 2'den daha yüksek aslına uygun bir geçiş istiyorsanız, verileri taşımak için genel API'leri kullanan çeşitli araçlar arasından seçim yapabilirsiniz.

API tabanlı geçiş sınırlamaları

API tabanlı geçişte aşağıdaki sınırlamalar oluşur:

  • Düşük uygunluk geçişi:
    • Sınırlama: API tabanlı araçlar, el ile kopyalamaya göre daha yüksek aslına uygunluk sağlar ancak yine de nispeten düşük aslına uygunluk sağlar.
    • Etki: Bu araçlar biraz aslına uygunluk sunsa da verilerinizin tüm yönlerini korumaz.
      • Örnek: Hiçbiri TFVC değişiklik kümelerinin özgün tarihlerini (Team Foundation Sürüm Denetimi) tutmaz.
      • Birçoğu, iş öğesi düzeltmelerinin değişen tarihlerini de korumaz.
  • Veri kaybı ve kimlik değişiklikleri:
    • Sınırlama: Geçiş sırasında araçlar iş öğesi değişikliklerini, TFVC değişiklik kümelerini, paket akışlarını ve işlem hattı yapıtlarını yeniden yürütmektedir.
    • Etki: Bu işlem veri kaybına neden olabilir, yeni kimlikler oluşturabilir ve oluşturma, değiştirme ve kapatma tarihlerini değiştirebilir.
      • Örnek: Belirli tarihlere bağlı geçmiş bağlam kaybolabilir ve bu da raporlamayı ve izlenebilirliği etkileyebilir.

API tabanlı geçiş işlemi

Genel olarak, bu yaklaşımı yalnızca el ile kopyanın ötesinde fazladan uygunluk kritikse öneririz. Bu yaklaşımı benimsemeye karar verirseniz, bir veya daha fazla araçla deneyimi olan bir danışman işe almayı ve son geçişinizden önce bir test geçişi yapmayı düşünebilirsiniz.

Birçok kuruluş, çalışmalarının yalnızca bir alt kümesi için çok yüksek aslına uygun bir geçişe ihtiyaç duyar. Yeni çalışmalar doğrudan Azure DevOps Services'da başlatılabilir. Daha az sıkı uygunluk gereksinimleri olan diğer çalışmalar, diğer yaklaşımlardan biri kullanılarak geçirilebilir.

Desteklenen işlem modelleri

Azure DevOps Services aşağıdaki işlem modellerini destekler:

Varsayılan olarak, Azure DevOps Services'da Barındırılan XML kapalıdır. Geçiş sırasında Barındırılan XML işlem modelini yalnızca Azure DevOps Server'da bir projeyi özelleştirdiyseniz açarız. Projeniz Barındırılan XML'ye eklendikten sonra, geçiş sonrasında devralınan XML'e yükseltebilirsiniz.

Temel ilkeler

Azure DevOps Services'a geçiş yaparken aşağıdaki temel ilkeleri ve sınırlamaları göz önünde bulundurun:

  • Azure DevOps Services yalnızca İngilizcedir: Azure DevOps Server birden çok dili destekler, ancak bugün Azure DevOps Services yalnızca İngilizceyi destekler. Koleksiyonunuz geçmişte İngilizce olmayan veya İngilizce olmayan bir dil kullanıyorsa ve yükseltme sırasında dili İngilizceye dönüştürdüyseniz, Veri Geçiş Aracı'nı kullanamazsınız.
  • Devralma: Çevik, Scrum veya CMMI işlem şablonundan oluşturulan ve hiçbir zaman özelleştirilmeyen bir proje, geçişten sonra Devralma işlemi modelinde yer alır.
  • Barındırılan XML: Özelleştirmeleri olan tüm projelerde Barındırılan XML işlem modeli kullanılır.
  • Özelleştirilmiş proje başına işlem: Azure DevOps Services projelerin bir işlemi paylaşmasına izin verse de, Veri Geçiş Aracı özelleştirilmiş her takım projesi için bir Barındırılan XML işlemi oluşturur. Örneğin, 30 özelleştirilmiş projeniz varsa, yönetebileceğiniz 30 Barındırılan XML işlemi vardır. Barındırılan XML işleminizi tüm projeleriniz için daha fazla özelleştirmek istiyorsanız, her Barındırılan XML işlemini ayrı ayrı güncelleştirmeniz gerekir.
  • İşlem doğrulama: Veri Geçiş Aracı'nın işlem doğrulaması, her proje için hedef işlem modelini algılar. Geçiş yapmadan önce Barındırılan XML projeleri için işlem doğrulama hatalarını düzeltmeniz gerekir. Devralma işlemi modelinden yararlanmak için projelerinizin sürecini süreçlerimizden biriyle (Çevik, Scrum veya CMMI) eşleşecek şekilde güncelleştirmeyi düşünebilirsiniz. Belgelerimizdeki süreç doğrulama türleri hakkında daha fazla bilgi edinin.

Kaynaklar

Sonraki adımlar