GitLab.com’dan Kendi Sunucunuzda Barındırılan GitLab’a Taşıma

Bir ekip GitLab.com'dan kendi örneğine taşındığında kod işin yalnızca bir parçasıdır. Sorunların (issues), birleştirme isteklerinin (merge requests), etiketlerin, kilometre taşlarının ve geçmişlerinin de taşınması gerekir, tercihen elle kopyalama yapmadan.

GitLab'ın bunun için direct transfer adlı yerleşik bir yöntemi vardır. Örneğiniz, kişisel erişim belirteci ile HTTPS üzerinden GitLab.com'a bağlanır ve bir grubu projeleriyle birlikte kopyalar. İçe aktarma arka planda çalışır ve bittiğinde taşınan her öğeyi kontrol edebilirsiniz.

Bu kılavuz bir grubun tam taşınmasını gösterir: GitLab.com'un hazırlanması, içe aktarmanın başlatılması, sonucun kontrol edilmesi ve direct transfer'in kapsamadığı adımların tamamlanması. Tüm adımlar, GitLab.com'dan Ubuntu 26.04 üzerindeki GitLab 19.5'e yapılan gerçek bir taşıma ile test edilmiştir.

Taşımadan önce neye ihtiyacınız var

Kurulu ve çalışan, kendi sunucunuzda barındırılan bir GitLab örneği. Henüz yoksa önce kurun, bkz. Dedicated sunucuya GitLab nasıl kurulur kılavuzu.

GitLab örneğinize yönetici erişimi.

GitLab.com'da taşımak istediğiniz grupta Owner rolü. İçe aktarma sayfası yalnızca Owner olduğunuz grupları listeler.

Sunucunuzdan https://gitlab.com adresine giden HTTPS erişimi.

Taşıyacağınız tüm depolar için sunucuda yeterli boş disk alanı ve /tmp içinde boş alan: GitLab geçici taşıma arşivlerini orada açar.

Bu kılavuz boyunca gitlab.example.com ifadesini kendi örneğinizin alan adıyla değiştirin.

Neler taşınır

Direct transfer şunları taşır:

• grubu ve projelerini;
• tüm dalları ve commit geçmişiyle depoları, commit karmaları aynı kalır;
• özgün numaralarıyla sorunları ve birleştirme isteklerini;
• etiketleri, kilometre taşlarını ve etkinlik geçmişini;
• özgün oluşturma tarihlerini.

İçe aktarılan katkılar ve bazı üyelikler önce yer tutucu (placeholder) kullanıcılara bağlanır. İçe aktarmadan sonra bunları örneğinizdeki gerçek hesaplara yeniden atarsınız.

Direct transfer şunları taşımaz:

• CI/CD değişkenlerini, pipeline zamanlama değişkenlerini ve pipeline tetikleyicilerini;
• deploy key'leri ve deploy token'ları;
• container registry imajlarını ve paket kayıt defterini;
• CI/CD iş günlüklerini ve iş artefaktlarını;
• webhook'ları;
• ortamları ve feature flag'leri;
• birleştirme isteği onay kurallarını ve bağlantılı sorunları;
• uzak yansıları (remote mirrors).

Pipeline'lar durumlarıyla birlikte kayıt olarak taşınır, ancak iş günlükleri ve artefaktlar olmadan.

GitLab.com hesabınızı hazırlama

E-postanızı herkese açık yapın. GitLab.com'da sağ üst köşedeki avatarınızı, ardından Edit profile seçeneğini seçin. Public email alanında e-posta adresinizi seçin ve sayfanın altındaki Update profile settings seçeneğini seçin.

Kişisel erişim belirteci oluşturun. Örneğiniz bu belirteci GitLab.com'daki verilerinizi okumak için kullanır. Profilinizin sol menüsünde Access > Personal access tokens bölümüne gidin.

Generate token seçeneğini, ardından Legacy token seçeneğini seçin.

Formu doldurun:

• Token name: herhangi bir ad, örneğin migration.
• Expiration date: taşıma için birkaç gün yeterlidir.
• Select scopes: api seçeneğini seçin. read_api ile karıştırmayın.

Generate token seçeneğini seçin. glpat- ile başlayan belirteci kopyalayın ve güvenli bir yere kaydedin. GitLab.com onu yalnızca bir kez gösterir.

Örneğinizde direct transfer'i etkinleştirme

GitLab örneğinizde yönetici olarak oturum açın. Sağ üst köşeden Admin seçeneğini seçin, Settings > General bölümüne gidin ve Import and export settings alanını genişletin. Allow migrating GitLab groups and projects by direct transfer altında Enabled onay kutusunu işaretleyin ve Save changes seçeneğini seçin.

Aynı bölümde, içe aktarmadan sonra kullanıcıların yeniden atanmasını etkileyen iki ayarı kontrol edin:

• Allow contribution mapping to administrators: etkinse katkıları yönetici hesaplarına da yeniden atayabilirsiniz;
• Skip confirmation when administrators reassign placeholder users: etkinse katkılar kullanıcının onayı olmadan hemen yeniden atanır.

Örneğinizi GitLab.com'a bağlama

Üst çubukta Create new (artı simgesi) seçeneğini, ardından New group > Import group seçeneğini seçin.

Bağlantı formunu doldurun:

• GitLab source instance base URL: https://gitlab.com
• Personal access token: GitLab.com'da oluşturduğunuz belirteç.

Connect instance seçeneğini seçin.

GitLab.com'daki gruplarınızın listelendiği Import groups by direct transfer sayfası açılır.

İçe aktarmayı başlatma

Listede grubu bulun. Path of the new group alanında Select parent group seçeneğini açın ve grubun nereye yerleştirileceğini seçin:

• No parent, GitLab.com'daki gibi üst düzey bir grup oluşturur;
• örneğinizdeki mevcut bir grup, grubu kendi içine alt grup olarak aktarır. Üst grup özelse GitLab.com'daki herkese açık gruplar ve projeler içe aktarmadan sonra özel olur.

Yeni grubun yolunu kontrol edin, varsayılan olarak GitLab.com'daki adla eşleşir. Grup üyelerinin taşınması için Import user memberships seçeneğini işaretli bırakın.

Grubun satırında Import with projects seçeneğini seçin. Durum Importing olarak değişir.

İçe aktarma arka planda çalışır, bu nedenle sayfayı kapatabilirsiniz. Süre projelerin sayısına ve boyutuna bağlıdır: testimizde iki küçük projeli bir grup yaklaşık iki dakika sürdü.

Sonucu kontrol etme

İçe aktarma bittiğinde durum Complete olarak değişir.

Durum Failed veya Partially completed ise hangi öğelerin içe aktarılmadığını görmek için Show errors seçeneğini seçin. Başarısız veya kısmi bir taşımayı aynı sayfadan veya API üzerinden yineleyebilirsiniz.

Migration details seçeneğini seçin. Migration history sayfası grubu ve her projeyi kendi durumuyla gösterir.

İçe aktarılan grubu açın ve içeriğini kontrol edin.

Projeler. Grubun tüm projeleri listede olmalıdır.

Sorunlar ve birleştirme istekleri. Grup menüsünde Work items ve Merge requests bölümlerini açın. Numaralar, etiketler ve kilometre taşları korunur ve içe aktarılan öğelerde Imported rozeti bulunur.

Depo. Bir projede Code > Branches bölümüne gidin. Beklenen tüm dalların bulunduğunu ve son commit'lerinin kaynak depoyla eşleştiğini kontrol edin.

Bir birleştirme isteği Cannot be merged automatically gösteriyorsa onu açın ve Changes sekmesini kontrol edin. Hiç değişiklik göstermiyorsa birleştirme isteğinin GitLab.com'da da commit'i yoktu, dolayısıyla birleştirilecek bir şey yoktur. Bu bir taşıma hatası değildir.

CI/CD değişkenlerini yeniden oluşturma

GitLab.com'da projeyi açın ve Settings > CI/CD bölümüne gidin, Variables alanını genişletin ve her değişkeni seçenekleriyle birlikte not edin, örneğin Protected ve Masked.

Kendi örneğinizde aynı projeyi ve aynı bölümü açın. Proje değişkenleri listesi boştur.

Add variable seçeneğini seçin ve her değişkeni aynı anahtar, değer ve seçeneklerle oluşturun. Grup değişkenleri kullanıyorsanız bunları da aynı şekilde yapın.

Pipeline zamanlamaları değişkenleri olmadan taşınır. Zamanlamalarınız değişken kullanıyorsa projede Build > Pipeline schedules bölümünü açın ve bunları her zamanlamaya ekleyin.

Yer tutucu kullanıcıları yeniden atama

İçe aktarma sırasında GitLab, katkı yazarları ve GitLab.com'dan içe aktarılan üyeler için yer tutucu kullanıcılar oluşturur. Bunların sorunlarını, birleştirme isteklerini ve yorumlarını gerçek hesaplara bağlamak için yer tutucuları yeniden atayın. Önce ekibinizin hesaplarını örnekte oluşturun, böylece atanacak kişiler olur.

Üst düzey grubu açın, yani alt grup olarak içe aktardıysanız içe aktarılan grubun kendisini veya üst grubunu, Manage > Members bölümüne gidin ve Placeholders sekmesini seçin. Bu grupta Owner rolüne ihtiyacınız var. Awaiting reassignment listesi tüm yer tutucu kullanıcıları gösterir.

Bir yer tutucunun satırında Select user seçeneğini açın ve örneğinizdeki hesabı seçin. Doğru satırda doğru hesabın seçildiğinden emin olun, ardından Reassign ve Confirm reassignment seçeneklerini seçin.

Durum Reassigning olarak değişir. Bir dakika sonra sayfayı yenileyin: yer tutucu Reassigned sekmesine taşınır.

Sorun artık yazar olarak gerçek hesabı gösterir ve özgün oluşturma tarihi korunur.

GitLab.com'un hizmet hesapları, örneğin Duo Code Review, de yer tutucu olarak gelir. Örneğinizde karşılıkları yoktur: olduğu gibi bırakın veya Do not reassign seçeneğini seçin. Çok sayıda kullanıcı için aynı sekmedeki Reassign with CSV file seçeneğini kullanın.

Taşımayı tamamlama

Belirteci iptal edin. GitLab.com'da Access > Personal access tokens bölümüne gidin ve taşıma belirtecinin yanındaki Revoke seçeneğini seçin.

Geliştirici makinelerinde uzak adresi güncelleyin. Bir deponun her yerel kopyasında Git'i örneğinize yönlendirin:

git remote set-url origin [email protected]:group/project.git

group/project ifadesini projenin örneğinizdeki yoluyla değiştirin.

Entegrasyonları ve otomasyonu yeniden kurun. Webhook'lar, deploy key'ler, deploy token'lar ve pipeline tetikleyicileri taşınmaz, bu yüzden bunları örneğinizde yeniden oluşturun. CI/CD runner'larını örneğinize kaydedin. Sohbet bildirimleri veya sorun takipçileri gibi harici hizmetleri her projenin ayarlarında yeniden bağlayın.

İçe aktarılan birleştirme isteklerinde yeni pipeline'lar çalıştırın. İçe aktarılan pipeline'lar özgün durumlarını korur ve yeniden çalışmadan Pipelines must succeed koşulunu karşılayabilir. İçe aktarılan bir birleştirme isteğini birleştirmeden önce örneğinizde onun için yeni bir pipeline çalıştırın.

Eski kopyayı kapatın. Her şey örneğinizde çalışmaya başladığında, kimsenin orada çalışmaya devam etmemesi için GitLab.com'daki grubu arşivleyin veya silin.

GitLab örneğiniz için sunucu seçmek üzere GitLab için Dedicated Sunucular sayfasına bakın.