Sürüm kontrolü ile işlem hattı projelerinizi yönetin

Bir işlem hattı projesinin geliştirilmesini yönetmek ve değişiklikleri takip etmek için sürüm kontrolünü kullanabilirsiniz.

Sürüm kontrolü ile çalışırken, tasarım sırasında projelerin sürümlerini işleyebilirsiniz (commit). Bu, projenin iki sürümü arasındaki değişiklikleri görmenizi sağlar. Ayrıca veri projelerinizi bir dallanma stratejisi kullanarak da geliştirebilirsiniz. Bu, her çalışma alanında veya dalda projenin yalıtılmış bir sürümü üzerinde çalışmanıza olanak tanır. Çalışma alanı birkaç kullanıcı tarafından paylaşılabilir. Daha sonra üretime dağıtım için çalışma alanındaki değişikliklerinizi bir ana dalla birleştirebilirsiniz.

Sürüm kontrolü için sağlayıcı olarak GitHub kullanılır. Uygulama, paylaşılan depo modelini izler.

• GitHub Enterprise Cloud ve GitHub Enterprise Server desteklenmez.

• Paylaşılan depo modeli hakkında daha fazla bilgi için bkz. İşbirlikçi geliştirme modelleri hakkında.

• Git ve GitHub hakkında daha fazla bilgi için bkz. GitHub ve Git hakkında.

• GitHub güvenlik hususları

  Qlik Talend Cloud, GitHub için varsayılan kimlik doğrulama modu olan HTTPS güvenlik protokolünü ve Kişisel Erişim Belirteçlerini (PAT) destekler. Daha fazla bilgi için bkz. GitHub'da kimlik doğrulama hakkında.

Başlarken

• GitHub'da kiracının GitHub'a erişmek için kullanabileceği bir kullanıcı oluşturun. Bu, bir yönetici tarafından sizin için zaten oluşturulmuş olabilir.

  Kullanıcı aşağıdaki kapsamlara sahip olmalıdır:

  • repo

  • read:org

  • read:user

  • read:project

• Değiştirmeyi planladığınız depolar üzerinde yazma erişimine ihtiyacınız vardır.

• Bir GitHub kişisel erişim belirteci (klasik) oluşturmalısınız. İnce taneli kişisel erişim belirteçleri desteklenmez.

  Daha fazla bilgi için GitHub belgelerine bakın: Kişisel erişim belirteçlerinizi yönetme.

• GitHub yapılandırmasında organizasyon zorunludur.

• Sürüm kontrolü eylemlerini gerçekleştirmek için projenin bulunduğu alanda Düzenleyebilir rolüne ihtiyacınız vardır.

• Sürüm kontrolünü kullanmaya başlamadan önce, oluşturduğunuz GitHub kullanıcısıyla GitHub'a bağlanmak için bir yapılandırma ayarlamalısınız.

  GitHub yapılandırmasını ayarlama

• GitHub'a bir bağlantı kurduğunuzda, bir projeyi bir depoya bağlayabilirsiniz.

  Bir projeyi bir depoya bağlama

GitHub yapılandırmasını ayarlama

Sürüm kontrolü ile çalışmak isteyen tüm kullanıcılar, bir GitHub kullanıcı hesabı kullanarak GitHub'a bağlanmak için bir yapılandırma ayarlamalıdır.

GitHub'ı İşlem hattı projeleri içinde veya kullanıcı profili ayarlarınızda yapılandırabilirsiniz. Başlarken bölümüne göre hazırlandığınızdan emin olun.

İşlem hattı projeleri içinde GitHub'ı yapılandırmak için:

1. ve ardından GitHub yapılandırması öğesine tıklayın.

2. Organizasyonunuzu ve Başlarken bölümünde açıklanan GitHub kişisel erişim belirtecini kullanarak kimlik doğrulamayı ayarlayın.

3. Tamam'a tıklayın.

Artık projelerinizi bir depoya bağlayabilirsiniz.

Bir projeyi bir depoya bağlama

Sürüm kontrolünü kullanmaya başlamadan önce bir projeyi bir depoya bağlamalısınız. GitHub'a bir bağlantı kurduğunuzdan emin olun.

1. İşlem hattı projeleri içinde, bir projedeki ... simgesine tıklayın ve Sürüm kontrolüne bağlan'ı seçin.

2. Projenin ilişkilendirileceği depoyu seçin.

3. Bir temel dizin yolu ekleyin.

   GitHub'daki mevcut bir projeye bağlanmak istiyorsanız, aynı yolu kullanmalısınız.

4. Bağlantıdan sonra projeyi işlemeyi (commit) ve uzak depoya göndermeyi (push) seçebilirsiniz. Bir işleme mesajı girin.

   İşleme ve gönderme yapmazsanız, çalışma alanında bir ana dal oluşturulur, ancak uzak depoda oluşturulmaz.

5. Bağlan'a tıklayın.

Proje artık seçilen depoya bağlanmıştır. Bu, proje kartının altında , deponun adı ve geçerli dal ile belirtilir.

Projeyi açtığınızda, başlık satırı artık sürüm kontrolü seçeneklerini içeren bir GitHub menüsü içerecektir. Proje adına ayrıca geçerli dalın adı da eklenecektir.

Sürüm kontrolü ile bir proje geliştirme

Sürüm kontrolünü farklı yaklaşımlarla kullanabilirsiniz:

• Doğrudan ana dal üzerinde çalışmak. Bu, temel olarak bir projede değişiklikleri takip etmek isteyen tek bir geliştirici için uygundur, ancak senkronize çalışan bir grup geliştirici tarafından da kullanılabilir.

• Birden fazla geliştiricinin katkıda bulunabileceği bir dallanma stratejisi ile çalışmak. Ayrıca yeni özellikleri veya değişiklikleri birbirinden yalıtmak için dallar oluşturabilirsiniz.

Tek geliştiricili bir proje için basitleştirilmiş iş akışı

Doğrudan bir projenin ana dalı üzerinde çalışabilirsiniz. Bu yaklaşım daha basittir ve daha az işlem içerir, ancak yine de değişiklikleri takip etmenizi sağlar. Birden fazla geliştirici varsa, senkronize olmaya dikkat etmeleri gerekir.

Projeye uygulamak istediğiniz değişiklikleri yaptığınızda, sadece bir İşle ve Gönder (Commit and Push) işlemi yapın.

Çok geliştiricili bir proje için iş akışı

Bu iş akışı, bir projede çalışan birden fazla geliştirici varsa veya değişiklikleri yalıtmak istiyorsanız kullanılabilir. Bu, diğer kullanıcılarla paylaşabileceğiniz bir geliştirme dalı oluşturmayı içerir. Bu iş akışıyla geliştiriciler birbirlerinin değişikliklerini takip edebilir ve değişiklikleri ana dalla ne zaman birleştireceklerine karar verebilirler.

1. Yeni bir dal oluşturun

   Ana daldan yeni bir geliştirme dalı oluşturun. Dalı daha fazla kullanıcıyla paylaşabilirsiniz.

2. Geliştirin

   Projede gerekli tüm değişiklikleri yapın.

   Bilgi notuVeritabanı şemaları ve bağlantılar sürüm kontrolünde tutulmaz.

3. Uzak değişiklikleri uygulayın

   Diğer daldaki değişikliklerle güncel olduğunuzdan emin olmak için başka bir daldaki uzak değişiklikleri çalışma alanınıza uygulayın. Bu, çakışan değişiklikleri önlemeye veya azaltmaya yardımcı olur.

   Çakışabilecek değişiklikler içeren iki dalınız varsa, geçici bir çözüm şudur:

   1. Değişiklikleri her iki çalışma alanına da işleyin.

   2. Her iki dalı da ana dalla birleştirin.

   3. Uzak değişiklikleri tekrar uygulayın.

4. İşle ve gönder

   Değişikliklerinizi geliştirme dalına işleyin ve gönderin. Tüm nesneler gönderilecektir, bu nedenle işlemeden önce projenizi doğrulamak iyi bir fikirdir.

5. Bir çekme isteği (pull request) oluşturun ve birleştirin

   Geliştirme ile hazır olduğunuzda, çalışma alanındaki değişiklikleri ana dalla birleştirme zamanı gelmiştir.

   Çekme isteğini proje sürüm kontrolünde oluşturabilirsiniz, ancak birleştirme işlemi onayları da ayarlayabileceğiniz GitHub'da gerçekleştirilmelidir. Daha fazla bilgi için bkz. GitHub Çekme istekleri belgeleri

Yeni bir dal oluşturma

1. Projede GitHub öğesine tıklayın ve Yeni dal oluştur'u seçin.

   Proje sürüm kontrolüne bağlı olmalıdır. Ayrıca projenin hedef bağlantısının bulunduğu alana erişim izniniz olmalıdır.

2. Ana daldan bir dal oluşturmayı seçin.

3. Dal için bir ad girin.

4. Tüm şemalar için dal öneki bölümünde projedeki tüm şemalara eklenecek bir önek ayarlayın. Bu, adlandırma çakışmalarını önlemek için tüm şemaların benzersiz şekilde adlandırılmasını sağlar.

5. Oluştur'a tıklayın

Ana daldan yeni bir dal oluşturulur ve depodan teslim alınır (checked out). Dal, tüm görevlerin Yeni durumunda olduğu projenin yeni bir sürümünü içerir. Yani, hazırlanmamışlardır ve herhangi bir veri içermezler.

Uzak değişiklikleri uygulama

Uzak depodaki değişiklikleri çalışma alanınıza uygulayabilirsiniz. Bunlar, örneğin GitHub'da veya diğer araçlar tarafından Qlik Cloud entegre sürüm kontrolü dışında oluşturulan değişiklikler olabilir. Bu, değişikliklerinizi dala işlemek ve göndermek istediğinizde çakışmaları önlemenize yardımcı olur.

1. Projede GitHub öğesine tıklayın ve Uzak değişiklikleri uygula'yı seçin.

   Değişiklik bulunursa Uzak değişiklikleri çalışma alanına uygula iletişim kutusu görüntülenir.

2. Artık hangi görevler için değişiklik uygulanacağını seçebilir ve değişiklikleri inceleyebilirsiniz. Her değişiklik için hangi sürümün kullanılacağını, uzak sürümü veya çalışma alanınızdaki sürümü seçebilirsiniz.

   Proje ile içe aktarılan proje arasında farklı olan bağlantıları eşlemek için gerekli değişiklikleri yapın.

   Örneğin, içe aktarılan proje SQL1 adlı bir kaynak bağlantısı kullanıyor olabilirken, bu proje SQL2 adlı benzer bir bağlantı kullanıyor olabilir. Bu durumda, içe aktarılan bağlantıyı Orijinal sürümde eklenen görevler için bağlantıları ayarla bölümünde SQL2 ile eşleyin.

   Değişiklikler projeler arası kaynaklar içeriyorsa ve başvurulan proje sürüm kontrolü altındaysa, her projeler arası kaynak için bir Dal seçici mevcuttur. Tüketilecek dalı seçin. Başvurulan proje sürüm kontrolü altında değilse, dal seçici gösterilmez.

   Bilgi notuEşlenecek bir bağlantı seçerken yeni bir veritabanı bağlantısı oluşturabilirsiniz, ancak bir SaaS uygulama bağlantısı oluşturamazsınız.

3. Uzak değişiklikleri uygula'ya tıklayın

Değişiklikler yeni veri görevleri içeriyorsa kaynak bağlantıları ve hedef bağlantıları eklemelisiniz.

İşleme ve gönderme

Değişikliklerinizi dala işleyebilir ve gönderebilirsiniz. Çalışma alanınıza uygulanmayan uzak değişikliklerin üzerine yazılabileceğinden, işleme ve gönderme işleminden önce Uzak değişiklikleri uygula işlemini gerçekleştirmelisiniz.

1. Projede GitHub öğesine tıklayın ve İşle ve gönder'i seçin.

   Değişiklik bulunursa İşle ve gönder iletişim kutusu görüntülenir.

2. Nelerin değiştiğini takip etmenize yardımcı olabilecek bir işleme mesajı ekleyin.

3. İşle ve gönder'e tıklayın

Bir çekme isteği oluşturma

Çalışma alanındaki değişiklikleri ana dalla birleştirmek için bir çekme isteği (PR) oluşturun.

1. Projede, bir proje üzerindeki GitHub öğesine tıklayın ve Çekme isteği oluştur'u seçin.

   Çekme isteği oluştur iletişim kutusu görüntülenir.

2. Çekme isteğinin bir başlığını ve açıklamasını ekleyin.

   Ayrıca oluşturulduktan sonra çekme isteğini GitHub'da açmayı da seçebilirsiniz.

3. Çekme isteği oluştur'a tıklayın.

Artık çekme isteği için onayları ayarlayabilir ve birleştirme işlemini GitHub'da gerçekleştirebilirsiniz.

Bir dalı silme

Değişikliklerinizi ana dalla birleştirdiğinizde bir dalı silebilirsiniz.

1. Projede, silinecek dalın üzerine tıklayın ve Dalı sil'i seçin.

   Sürüm kontrolündeki uzak dalı da silmeyi seçebilirsiniz.

   İşlenmemiş değişiklikler varsa, dalı silerken bu değişikliklerin kaybolacağını onaylamanız gerekecektir.

Bir proje için sürüm kontrolünü kaldırma

Projenizin sürüm kontrolüyle bağlantısını kesebilirsiniz. Mevcut dallar varsa, projenin bağlantısını kesmeden önce bunların silinmesi gerekir.

1. İşlem hattı projeleri içinde, bağlantısını keseceğiniz projedeki ... simgesine tıklayın ve GitHub bağlantısını kes'i seçin.

Sürüm kontrolünden bir projeyi içe aktarma

Örneğin başka bir geliştiricinin projesini incelemek veya bir projede işbirliği yapmak istiyorsanız, sürüm kontrolünden bir projeyi içe aktarabilirsiniz. Sürüm kontrolünden bir projeyi içe aktarmak, bir projenin diğer alanlar veya kiracılarla paylaşılmasını da sağlar. Bir projenin bir sürümünü aynı kiracıdaki farklı bir alanla veya başka bir kiracıyla paylaşabilirsiniz. Bu, örneğin biri geliştirme ve diğeri üretim için olmak üzere iki ortam oluşturmak istediğinizde kullanışlıdır."

Bir projeyi içe aktarmadan önce

Bir projeyi içe aktarmaya başlamadan önce:

• Yeni bir kiracıya veya alana içe aktarıyorsanız ihtiyaç duyacağınız tüm yeni bağlantıları oluşturun.

• Proje, kiracıda veya alanda henüz mevcut olmayan SaaS uygulama bağlantıları kullanıyorsa, içe aktarmaya başlamadan önce bağlantıları oluşturmalı ve meta veriler oluşturmalısınız.

• Projeler arası bir işlem hattını içe aktarıyorsanız, önce yukarı akış projelerini içe aktarmalısınız.

Bir projeyi içe aktarma

Proje diğer projelerden görevler tüketiyorsa, alanlar ve projeler için adlar aynı olmadığı sürece projeleri ve görevleri eşlemelisiniz.

1. Veri Entegrasyonu > Projeler bölümünde, Yeni oluştur'a tıklayın ve Projeyi sürüm kontrolünden içe aktar'ı seçin.

2. Depoyu seçin ve ardından dalı seçin.

   Gerekirse temel dizin yolunu seçin ve Projeleri göster'e tıklayın.

   Listeden içe aktarılacak projeyi seçin.

   İleri'ye tıklayın.

3. Yeni proje için Proje özellikleri'ni ayarlayın.

   Alan bölümünde projenin ekleneceği alanı seçmelisiniz.

   Veri platformu bölümünde projenin veri platformunu ve veri platformuna olan bağlantıyı değiştirebilirsiniz.

   Başka bir kiracıdan bir proje içe aktardıysanız veya önceki adımda veri platformunu değiştirdiyseniz Bağlantı'yı değiştirmek gerekir.

   Hazırlama alanına olan bağlantıyı değiştirebilirsiniz. Başka bir kiracıdan bir proje içe aktardıysanız veya bazı durumlarda önceki adımda veri platformunu değiştirdiyseniz bu gereklidir.

   İleri'ye tıklayın.

4. Yeni proje için Varsayılan proje ayarları'nı ayarlayın.

   Tüm şemalar için önek bölümünde projede oluşturulan veri şemalarına bir önek ekleyebilirsiniz. Bu, içe aktarılan proje dışa aktarılan projeyle aynı bulut veri deposunda olduğunda kullanışlıdır.

   Ayrıca Veritabanı adı bölümünde varsayılan bir ad ayarlayabilirsiniz. Snowflake projeleri için varsayılan bir Veri ambarı adı ayarlayabilir ve Databricks projeleri için varsayılan bir Katalog adı ayarlayabilirsiniz. Tüm görev türleri için proje varsayılan adını kullanabilir veya her görev türü için adı varsayılan veya özel bir ad olarak ayarlayabilirsiniz.

   İleri'ye tıklayın.

5. Bağlantılar ve görev ayarları'nı ayarlayın.

   İçe aktarılan kaynak bağlantılarını veya projeler arası kaynakları değiştirebilirsiniz. Başka bir kiracıdan bir proje içe aktardıysanız bu gereklidir.

   Projeler arası bir kaynağı sürüm kontrolü altındaki bir projeyle eşlerken, bir Dal seçici mevcuttur. Tüketilecek başvurulan projenin dalını seçin. Başvurulan proje sürüm kontrolü altında değilse, dal seçici gösterilmez. Projeler arası bir kaynak ana olmayan bir dalla eşlenirse, dal adı proje adının yanında parantez içinde gösterilir.

   İsteğe bağlı görev ayarları bölümünde, orijinal projede geçersiz kılınan görev ayarlarını da değiştirebilirsiniz.

6. Hazır olduğunuzda İçe aktar'a tıklayın.

Proje Veri Entegrasyonu ana sayfasına eklenir.

Sürüm kontrolünden içe aktarılan bir proje üzerinde çalışma

Birkaç farkla, normal sürüm kontrollü projelerle aynı şekilde çalışırsınız:

• Yalnızca ana dala veya sürüm kontrolünden içe aktarılan başka bir dala geçiş yapabilirsiniz.

• Bir daldan içe aktardıysanız, ana dal boş olacaktır.

• Bir projeyi silmek uzak sürümü silmez.

Güvenlik hususları

Qlik Talend Data Integration ve GitHub arasında senkronize güvenlik yapılandırmalarını koruduğunuzdan emin olun.

• Qlik Talend Data Integration içinde izinler, birkaç proje içerebilen alanlara dayanır. GitHub'da izinler, yine birkaç proje içerebilen depolara dayanır. En iyi uygulama, bunları hizalamak ve bir alandaki tüm projeleri aynı depoya bağlamaktır.

• Qlik Talend Data Integration ve GitHub'ın kullanıcılar için farklı izinler ve roller kullandığını unutmayın.

En iyi uygulamalar

Sürüm kontrolü kullanan projelerle çalışırken bazı genel en iyi uygulamalar şunlardır.

• GitHub'daki depoyu açıklayan bir README dosyası ekleyin. Daha fazla bilgi için bkz. README'ler hakkında.

  Boş bir depoyla başlarsanız, Qlik Talend Cloud sürüm kontrolü otomatik olarak boş bir README.md dosyası ekleyecektir.

• Genel olarak, GitHub deposunu Qlik Talend Cloud sürüm kontrolünün yönetmesine izin vermelisiniz.

• Yalnızca geçerli olan ve çalıştırılması test edilmiş projeleri işleyin.

  Hazırlanmamış veya dönüştürülmemiş İniş (Landing) veya Kayıtlı (Registered) veri görevlerine sahip projeler eklerseniz, kaynak sütunlar henüz dahil edilmez. Kaynak sütunlar, görev hazırlanıp dönüştürüldüğünde eklenir.

• Çoğaltma projeleri için bir dal oluşturduğunuzda, dalların varsayılan olarak aynı hedefi kullandığının farkında olmalısınız. Bu, daldaki görevleri çalıştırmanın ana sürümün verilerini geçersiz kılabileceği anlamına gelir. Veri kaybını önlemek için, daldaki hedef ayarlarını ana sürümle çakışmayacak şekilde değiştirin.

• Bir dal oluşturduğunuzda, çalışma alanına henüz uygulanmamış uzak değişiklikler olabilir. Uzak değişiklikleri atmak istemiyorsanız, dalı oluşturmadan önce veya sonra uzak değişiklikleri uygulayın.

• İki farklı dalda aynı veri kümesinde değişiklik yapmak, çözülmesi zor birleştirme çakışmalarına ve veri kümesinin yeniden oluşturulmasına neden olabilir.

  Bilgi notuBir göreve bir veri kümesi eklendiğinde, dahili bir tanımlayıcı alır. Dahili tanımlayıcılar, bir işlem hattında sorunsuz yeniden adlandırma ve diğer meta veri işlemlerine izin vermek için kullanılır. Aynı veri kümesini ayrı bir projede veya dalda oluştururken, dahili tanımlayıcı farklı olacaktır ve bu da iki dalı birleştirirken bir çakışmaya neden olabilir. Bu, hazırlama işleminin aynı ada sahip olsa bile bir veri kümesini bırakıp yeniden oluşturmasına neden olabilir.

Dallarda çalışma

Bir proje oluşturabilir, tasarlayabilir ve hazır olduğunda MAIN dalını kullanarak üretime dağıtabilirsiniz. MAIN üzerindeki sürüm, üretim işlem hattınıza karşılık gelir. İlk dağıtımdan sonra MAIN dalını asla doğrudan düzenlememelisiniz.

Bir geliştirici bir projede bir özellik eklemek veya bir hatayı düzeltmek gibi yeni bir değişiklik yapmak istediğinde, yeni bir dal oluşturulması gerekir.

Geliştiriciler geliştirme ihtiyaçları için istedikleri sayıda dal oluşturabilirler

• Değişiklikleri yaparken veritabanı çakışmalarını önlemek için dallar için şema önekleri kullanın.

• Bir dalda, geliştiriciler istedikleri sayıda değişiklik yapabilir ve gerektiği kadar işleyip (commit) gönderebilir (push). Her değişikliği kendi içinde bağımsız, ayrı bir işlemede yalıtmanız önerilir. Örneğin, veri reyonunu da etkileyen bir dönüştürme görevinde bir değişiklik yaparsanız, her iki değişikliği de tek bir işlemeye dahil ettiğinizden emin olun

• Tüm ekip üyeleri, özellikle değişikliklerini işlemeden önce MAIN dallarının güncel olduğundan emin olmak için istedikleri zaman Uzak değişiklikleri uygula seçeneğini kullanmalıdır.

Geliştiriciler dallarındaki çalışmalarını bitirdiklerinde, akran değerlendirmesi için bir çekme isteği oluşturabilirler.

Diğer ekip üyelerinin incelemesi ve onayından sonra, çekme isteğini GitHub'daki MAIN sürümüyle birleştirebilirsiniz.

Son olarak, onaylanan dal değişikliklerini tekrar MAIN dalına (üretim) çekmek için projede Uzak değişiklikleri uygula seçeneğini kullanın.

Alanlarda çalışma

Daha büyük ve kritik dağıtımlar için, değişiklikleri yalıtmak ve işlem hattı bütünlüğünü sağlamak amacıyla geliştirme ve üretim için ayrılmış alanlar kullanılması önerilir. Her alanda kaynaklar ve hedef için ayrılmış veri bağlantıları kullanın.

• Üretim

  MAIN dalı üretimde olanı yansıtır. Bu, bir projenin yalnızca bir MAIN sürümü olduğu anlamına gelir.

  Üretim, örneğin PROD gibi ayrılmış bir veri alanında yalıtılır. Üretim alanına ayrılmış bağlantılar atanır.

  Doğrudan üretim alanında/MAIN dalında hiçbir değişiklik yapılmaz. Tüm değişiklikler, dallar kullanılarak ayrılmış bağlantılara sahip diğer alanlarda yapılır.

  GitHub'daki mevcut bir projenin MAIN sürümünü yeniden kullanabilirsiniz. GitHub'daki mevcut projeyle aynı ada sahip boş bir proje oluşturun. Bu, düzenlemeye başlamak için MAIN dalındaki mevcut en son sürümü alır.

  Kullanıcılar yeni bir dal oluşturur, değişikliklerini yapar, çekme istekleri oluşturur, birleştirir ve tekrar MAIN/Üretim'e çeker.

• Geliştirme

  Geliştiriciler değişikliklerini örneğin DEV gibi ayrılmış bir veri alanında yalıtabilirler. DEV alanına ayrılmış bağlantılar atanır.

  Değişiklikler, genellikle geliştirici başına bir dal olmak üzere dallar kullanılarak yalıtılır. Değişiklikleri yaparken veritabanı çakışmalarını önlemek için bir dal oluşturulduğunda şema önekleri kullanın.

• İnceleme / kalite kabulü

  İnceleyenlere geliştirme alanlarına ve bağlantılara şu amaçlarla erişim izni verilir:.

  • Qlik Talend Cloud içinde proje dallarını açmak ve test etmek.

  • GitHub'da birleştirme işlemine devam etmek için çekme isteklerini onaylamak.

  • Onaylanan değişikliklerin ne zaman tekrar MAIN/Üretim'e çekilebileceği konusunda ekip üyelerini bilgilendirmek.

Onaylanan değişiklikleri tekrar MAIN/Üretim alanına dağıtırken, bağlantıları üretim alanı bağlantılarına yeniden atamalısınız.

Sınırlamalar

• Hedef olarak Qlik Cloud (QVD) olan projeler için sürüm kontrolü desteklenmez.

• Dallar varsa sürüm kontrolü kullanan bir projenin bağlantısını kesmek veya silmek mümkün değildir. Projenin bağlantısını kesmeden veya silmeden önce dallar silinmelidir.

• Sürüm kontrolü kullanan bir projeyi yeniden adlandırmak mümkün değildir.

• Bir kiracıyı sildiğinizde, GitHub'da sürüm kontrolü ile depolanan nesneler silinmez. Bu nesneleri manuel olarak silmeniz gerekir.

• bir depo birçok proje tarafından kullanılıyorsa veya Qlik Talend Data Integration içinde depolanmayan birçok dosya içeriyorsa, performans düşebilir.

• Veritabanı şemaları ve bağlantılar sürüm kontrolünde tutulmaz.

• GitHub ince taneli kişisel erişim belirteçleri desteklenmez.

• İki proje aynı depoda olsa bile, bir dal (ana dal hariç) depo başına yalnızca bir proje tarafından kullanılabilir.

• Farklı bir hedef platform kullanan bir projeden uzak değişiklikleri uygulamak mümkün değildir. Örneğin, Snowflake üzerindeki bir projede değişiklikleri işlerseniz, değişiklikleri bir Databricks projesine uygulayamazsınız.