Kuruluş yapınızı planlama

  • Makale

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure DevOps'ta oluşturduğunuz kuruluş, proje ve ekip sayısı için iş yapınızı kılavuz olarak kullanın. Bu makale, Azure DevOps için farklı yapılar ve senaryolar planlamanıza yardımcı olur.

Azure DevOps'ta iş ve işbirliği çalışmalarınız için aşağıdaki yapıları göz önünde bulundurun:

Aşağıdaki senaryoları planlamak da isteyebilirsiniz:

Şirketinizi, daha büyük kod projeleri koleksiyonunuzu, hatta birden çok ilgili iş birimini temsil eden en az bir kuruluşa sahip olun.

Kuruluş nedir?

Azure DevOps'taki bir kuruluş, ilgili proje gruplarını düzenlemeye ve bağlamaya yönelik bir mekanizmadır. Örnek olarak iş bölümleri, bölgesel bölümler veya diğer kurumsal yapılar verilebilir. Tüm şirketiniz için bir kuruluş, kendiniz için bir kuruluş veya belirli iş birimleri için ayrı kuruluşlar seçebilirsiniz.

Her kuruluş aşağıdaki gibi kendi ücretsiz hizmet katmanını (her hizmet türü için en fazla beş kullanıcı) alır. Tüm hizmetleri kullanabilir veya yalnızca mevcut iş akışlarınızı tamamlamak için gerekenleri seçebilirsiniz.

  • Azure Pipelines: CI/CD için ayda 1.800 dakika ve şirket içinde barındırılan bir iş ile barındırılan bir iş
  • Azure Boards: İş öğesi izleme ve Kanban panoları
  • Azure Repos: Sınırsız sayıda özel Git deposu
  • Azure Artifacts: Paket yönetimi
  • Sınırsız Paydaşlar
    • İlk beş kullanıcı ücretsiz (Temel lisans)
    • Azure Pipelines
    • Azure Boards: İş öğesi izleme ve Kanban panoları
    • Azure Repos: Sınırsız sayıda özel Git deposu
    • Azure Artifacts: Kuruluş başına iki GiB ücretsiz

Not

Azure DevOps bulut tabanlı yük testi hizmeti kullanım dışıdır, ancak Azure Yük Testi kullanılabilir durumda kalır. Bu tam olarak yönetilen yük testi hizmeti, mevcut Apache JMeter betiklerinizi kullanarak yüksek ölçekli yük oluşturmanıza olanak tanır. Daha fazla bilgi için bkz . Azure Yük Testi nedir? ve Visual Studio'da yük testi işlevselliğinde yapılan değişiklikler ve Azure DevOps'ta bulut yük testi.

Kaç kuruluşa ihtiyacınız var?

Azure DevOps'ta tek bir kuruluşla başlayın. Daha sonra farklı güvenlik modelleri gerektirebilecek daha fazla kuruluş ekleyebilirsiniz. Tek bir kod deposuna veya projeye yalnızca bir kuruluş gerekir. Kod veya diğer projeler üzerinde yalıtarak çalışması gereken ayrı ekipleriniz varsa, bu ekipler için ayrı kuruluşlar oluşturmayı göz önünde bulundurun. Farklı URL'leri olacaktır. Başka bir kuruluş eklemeden önce gerektiğinde projeleri, ekipleri ve depoları ekleyin.

İş yapınızı ve yönetilecek farklı iş gruplarını ve katılımcıları gözden geçirmek için biraz zaman ayırın. Daha fazla bilgi için bkz . Projelerinizi iş birimleriyle eşleme ve Yapı konuları.

İpucu

Şirkete ait Microsoft Entra kuruluşları için, IP'nizi korumanın bir yolu olarak kullanıcıların yeni kuruluşlar oluşturmasını kısıtlamayı göz önünde bulundurun. Daha fazla bilgi için bkz . Microsoft Entra kiracı ilkesi aracılığıyla kuruluş oluşturmayı kısıtlama. Kullanıcılar MSA veya GitHub hesaplarını hiçbir kısıtlama olmadan kullanarak kuruluş oluşturabilir.

Takım nedir?

Ekip, ekip tarafından yapılandırılabilen birçok aracı destekleyen bir birimdir. Bu araçlar, çalışmayı planlamanıza ve yönetmenize ve işbirliğini kolaylaştırmanıza yardımcı olur.

Her ayrı ürün veya özellik ekibi için bir ekip oluşturma

Her takımın kendi kapsamı vardır. Yeni bir kapsam oluşturmak için yeni bir ekip oluşturursunuz. Program sahiplerinin ekipler arasında ilerleme durumunu daha kolay izleyebilmesi, portföyleri yönetmesi ve toplama verileri oluşturması için ekipleri ve kapsamları hiyerarşik bir yapıda yapılandırın. Ekip oluşturduğunuzda bir ekip grubu oluşturulur. Bu grubu sorgularda veya ekibinizin izinlerini ayarlamak için kullanabilirsiniz.

Proje nedir?

Azure DevOps'taki bir proje aşağıdaki özellikler kümesini içerir:

  • Çevik planlama için panolar ve kapsamlar
  • Sürekli tümleştirme ve dağıtım için işlem hatları
  • Kaynak kodun ve yapıtların sürüm denetimi ve yönetimi için depolar
  • Proje yaşam döngüsü boyunca sürekli test tümleştirmesi Her kuruluş bir veya daha fazla proje içerir

Aşağıdaki görüntüde kurgusal Contoso şirketinin Contoso-Manufacturing kuruluşunda dört projesi vardır.

Dört projesi olan bir kuruluşun görüntüsü

Kaç proje gerekiyor?

Azure Boards, Azure Repos veya Azure Pipelines gibi bir Azure DevOps hizmetini kullanmaya başlamak için en az bir projeniz vardır. Kuruluşunuzu oluşturduğunuzda, sizin için varsayılan bir proje oluşturulur. Varsayılan projenizde çalışmaya başlamanız gereken bir kod deposu, çalışmayı izlemek için kapsam ve derleme ve yayını otomatikleştirmeye başlamak için en az bir işlem hattı vardır.

Bir kuruluş içinde aşağıdaki yaklaşımlardan birini yapabilirsiniz:

  • Çok sayıda depo ve takım içeren tek bir proje oluşturma
  • Her biri kendi ekip kümesine, depolara, derlemelere, iş öğelerine ve diğer öğelere sahip birçok proje oluşturma

Yüzlerce farklı uygulama ve yazılım projesi üzerinde çalışan birçok ekibiniz olsa bile, bunları Azure DevOps'taki tek bir projede yönetebilirsiniz. Ancak, yazılım projeleriniz ve ekipleri arasında daha ayrıntılı güvenlik yönetmek istiyorsanız, birçok proje kullanmayı göz önünde bulundurun. En yüksek yalıtım düzeyinde, her kuruluşun tek bir Microsoft Entra kiracısına bağlı olduğu bir kuruluş bulunur. Ancak tek bir Microsoft Entra kiracısı birçok Azure DevOps kuruluşuna bağlanabilir.

Not

Kuruluş için Belirli projelerde kullanıcı görünürlüğünü ve işbirliğini sınırla önizleme özelliği etkinleştirilirse, Proje Kapsamlı Kullanıcılar grubuna eklenen kullanıcılar, eklendikleri projelere erişemez. Daha fazla bilgi ve güvenlikle ilgili önemli çağrılar için bkz . Kuruluşunuzu yönetme, Projeler için kullanıcı görünürlüğünü sınırlama ve daha fazlası.

Tek proje

Tek bir proje, tüm çalışmaları kuruluşun tamamı için aynı "portföy" düzeyine getirir. Çalışmanız aynı depo kümesine ve yineleme yollarına sahiptir. Tek bir projeyle ekipler kaynak depolarını, derleme tanımlarını, yayın tanımlarını, raporları ve paket akışlarını paylaşır. Birçok ekip tarafından yönetilen büyük bir ürün veya hizmetiniz olabilir. Bu ekiplerin ürün yaşam döngüsü boyunca sıkı bağımlılıkları vardır. Bir proje oluşturur ve ekipleri ve alan yollarını kullanarak işi bölersiniz. Bu kurulum, ekiplerinize birbirlerinin çalışmaları hakkında görünürlük sağlar, böylece kuruluş uyumlu kalır. Ekipleriniz iş öğesi izleme için aynı taksonomiyi kullanarak iletişim kurmanızı ve tutarlı kalmanızı kolaylaştırır.

İpucu

Aynı ürün üzerinde birden çok ekip çalıştığında, tüm ekiplerin aynı yineleme zamanlamasına sahip olması, ekiplerinizin aynı tempoda hizalı ve değer sunmasını sağlar. Örneğin Azure DevOps'taki kuruluşumuzun tek bir projede 40'ın üzerinde özellik ekibi ve 500'den fazla kullanıcısı vardır. Bu iyi sonuç verir çünkü hepimiz ortak hedeflere ve ortak bir yayın zamanlamasına sahip ortak bir ürün kümesi üzerinde çalışıyoruz.

Yüksek hacimli sorgular ve panolar aradığınızı bulmanızı zorlaştırabilir. Ürününüzün mimarisine bağlı olarak, bu zorluk derlemeler, sürümler ve depolar gibi diğer alanlara taşabilir. İyi adlandırma kurallarını ve basit bir klasör yapısını kullandığınızdan emin olun. Projenize bir depo eklediğinizde stratejinizi göz önünde bulundurun ve bu deponuzun kendi projesine yerleştirilip yerleştirilemeyeceğini belirleyin.

Birçok proje

Ürünü nasıl sevk ettiğinize göre proje yapısını en iyi şekilde belirleyebilirsiniz. Çeşitli projelerin olması yönetim yükünü değiştirir ve ekip karar verdikçe ekiplerinize projeyi yönetmek için daha fazla özerklik verir. Ayrıca farklı projeler genelinde güvenlik ve varlıklara erişim üzerinde daha fazla denetim sağlar. Ancak, birçok projede takım bağımsızlığı olması bazı hizalama zorluklarına neden olur. Her proje farklı bir süreç veya yineleme zamanlaması kullanıyorsa, taksonomiler aynı değilse iletişim ve işbirliğini zorlaştırabilir.

İpucu

Tüm projelerinizde aynı işlemi ve yineleme zamanlamalarını kullanırsanız, ekipler arasında veri ve rapor alma beceriniz artar.

Azure DevOps, çalışmayı yönetmek için çapraz proje deneyimleri sağlar.

Aşağıdaki senaryolar nedeniyle başka bir proje eklemek isteyebilirsiniz:

  • Proje içindeki bilgilere erişimi yasaklama veya yönetme
  • Kuruluşunuzdaki belirli iş birimleri için özel iş izleme süreçlerini desteklemek için
  • Kendi yönetim ilkeleri ve yöneticileri olan tamamen ayrı iş birimlerini desteklemek için
  • Çalışma projesinde değişiklik yapmadan önce özelleştirme etkinliklerini test etme veya uzantı ekleme desteği sağlamak için

Birçok proje yapmayı düşünürken Git deposu taşınabilirliğinin, depoları (tam geçmiş dahil) projeler arasında geçirmeyi kolaylaştırdığını unutmayın. Projeler arasında diğer geçmiş geçirilemiyor. Gönderme ve çekme isteği geçmişi örnek olarak verilebilir.

Projeleri iş birimleriyle eşlediğinizde, şirketiniz tek bir kuruluşa sahip olur ve bir iş birimini temsil eden bir veya daha fazla proje içeren birçok proje ayarlar. Şirketin tüm Azure DevOps varlıkları bu kuruluşun içinde yer alır ve belirli bir bölgede (örneğin Batı Avrupa) bulunur. Projelerinizi iş birimlerine eşlemek için aşağıdaki kılavuzu göz önünde bulundurun:

Bir proje, birçok ekip Tek bir kuruluş, birçok proje ve ekip Birçok kuruluş
Genel rehber Daha küçük kuruluşlar veya yüksek düzeyde uyumlu ekiplere sahip daha büyük kuruluşlar için en iyi yöntemdir. Farklı çabalar farklı süreçler gerektirdiğinde iyidir. TFS eski geçişlerinin bir parçası olarak ve kuruluşlar arasındaki sıkı güvenlik sınırları için kullanışlıdır. Her kuruluşta birden çok proje ve ekiple kullanılır.
Ölçek On binlerce kullanıcıyı ve yüzlerce ekibi destekler, ancak tüm ekipler ilgili çalışmalar üzerinde çalışıyorsa en iyisi bu ölçektedir. Bir projede olduğu gibi, ancak birçok proje daha kolay olabilir.
Işlem Ekipler arasında uyumlu süreçler; panoları, panoları vb. özelleştirmek için ekip esnekliği. Her proje için bağımsız işlemler. Örneğin, farklı iş öğesi türleri, özel alanlar vb. Birçok projeyle aynı.
İş birliği Farklı ekiplerin iş ve varlıkları arasında en yüksek varsayılan görünürlük ve yeniden kullanım. İyi görünürlük ve yeniden kullanım mümkündür, ancak ister kasıtlı olsun, projeler arasında varlıkları gizlemek daha kolaydır. Kuruluşlar arasında düşük görünürlük, işbirliği ve yeniden kullanım.
Raporlama ve portföy yönetiminin toplanması Ekipler arasında toplanıp ekipler arasında koordinasyon sağlamak için en iyi özellik. Projeler arasında iyi raporlama mümkündür. Çapraz proje dağıtımı ve ekip koordinasyonu için daha zor. Kuruluşlar arasında bir top veya koordinasyon yoktur.
Güvenlik/yalıtım Varlıkları ekip düzeyinde kilitleyebilir, ancak varsayılan ayar açık görünürlük ve işbirliğidir. Projeler arasında kilitleme olanağı daha iyi. Varsayılan olarak, projeler içinde iyi görünürlük ve projeler arasında iyi yalıtım sağlar. Kuruluşlar arasında sert sınırlar; mükemmel yalıtım ve kuruluşlar arasında paylaşabilmek için minimum beceri.
Bağlam değiştirme Ekiplerin birlikte çalışması ve kullanıcıların eforlar arasında geçiş yapmaları en kolayıdır. Kullanıcıların birlikte çalışması ve bağlamları eforlar arasında değiştirmesi nispeten kolaydır. Farklı kuruluşlarda çalışmak zorunda olan kullanıcılar için daha zor.
Bilgi aşırı yüklemesi Varsayılan olarak, tüm varlıklar "bilgi aşırı yüklemesini" önlemek için "sık kullanılanlar" ve benzer mekanizmalar kullanan kullanıcılar tarafından görülebilir. Daha az bilgi aşırı yükleme riski; proje sınırları arasında gizlenen çoğu proje varlığı. Kuruluşlar genelindeki varlıklar yalıtılır ve bu da bilgilerin aşırı yüklenmesi riskini azaltır.
Yönetici ek yük Tek tek takımlara çok fazla yönetim devredilir. Kullanıcı lisanslama ve kuruluş düzeyinde yönetim için en kolayı. Eforlar arasında hizalama gerekiyorsa daha fazla çalışma gerekebilir. Proje düzeyinde daha fazla yönetim. Daha fazla ek yük, ancak projelerin farklı yönetim gereksinimleri olduğunda yararlı olabilir. Daha fazla projede olduğu gibi, kuruluşlar arasında daha fazla esneklik sağlayan daha fazla yönetim yükü vardır.

Proje içindeki yapı depoları ve sürüm denetimi

Daha önce oluşturduğunuz ve erişime ihtiyacı olan kuruluşlardan biri kapsamındaki belirli stratejik çalışmaları göz önünde bulundurun. Projeyi adlandırmak ve oluşturmak için bu bilgileri kullanın. Bu proje, oluşturduğunuz kuruluşta tanımlanmış bir URL'ye sahiptir ve bu url'ye https://dev.azure.com/{organization-name}/{project-name}.

Proje ayarları'nda projenizi yapılandırın.

Proje ayarları düğmesini gösteren ekran görüntüsü.

Projeleri yönetme hakkında daha fazla bilgi için bkz . Azure DevOps'ta projeleri yönetme. Verileri geçirerek projeyi farklı bir kuruluşa taşıyabilirsiniz. Projenizi geçirme hakkında daha fazla bilgi için bkz . Geçiş seçenekleri.

Sürüm denetimini yönetme

Azure Repos hizmetinin etkinleştirildiği projelerde sürüm denetimi depoları kodu depolayabilir ve düzeltebilir. Depoları yapılandırırken aşağıdaki seçenekleri göz önünde bulundurun.

Git ve Team Foundation Sürüm Denetimi (TFVC) karşılaştırması

Azure Repos, ekiplerin aralarından seçim yapacağı aşağıdaki sürüm denetim sistemlerini sunar:

  • Git ve TFVC. Projeler her türden depoya sahip olabilir. Varsayılan olarak, yeni projelerin boş bir Git deposu vardır. Git, geliştirici iş akışlarında büyük miktarda esneklik sağlar ve geliştirici ekosistemindeki neredeyse tüm ilgili araçlarla tümleşir. Herhangi bir proje Git depolarını kullanabilir. Bir projeye eklenebilen Git depolarının miktarında bir sınır yoktur.

TFVC, aynı zamanda kullanılabilen merkezi bir sürüm denetim sistemidir. Git'in aksine, bir proje için yalnızca bir TFVC deposuna izin verilir. Ancak bu depoda klasörler ve dallar, isterseniz birden çok ürün ve hizmetin kodunu düzenlemek için kullanılır. Projeler uygunsa hem TFVC hem de Git kullanabilir.

Bir ve çok depo karşılaştırması

Tek bir proje içinde birden çok depo ayarlamanız mı gerekiyor yoksa proje başına bir depo mu ayarlamanız gerekiyor? Aşağıdaki kılavuz, bu depolardaki planlama ve yönetim işlevleriyle ilgilidir.

Ürünler/hizmetler eşgüdümlü bir yayın zamanlaması üzerinde çalışıyorsa, birden çok depo içeren bir proje düzgün çalışır. Geliştiriciler sık sık birden fazla depoyla çalışıyorsa, işlemlerin paylaşıldığından ve tutarlı kaldığından emin olmak için bunları tek bir projede tutun. Erişim denetimleri ve büyük/küçük harf zorlama ve maksimum dosya boyutu gibi seçenekler proje düzeyinde ayarlandığından, depo erişimini tek bir proje içinde yönetmek daha kolaydır. Depolarınız tek bir projede olsa bile erişim denetimlerini ve ayarlarını tek tek yönetebilirsiniz.

Birden çok depoda depolanan ürünler bağımsız zamanlamalar veya süreçler üzerinde çalışıyorsa, bunları birden çok projelere bölebilirsiniz. Git deposu taşınabilirliği, depoları projeler arasında taşımayı ve yine de tam uygunluk işleme geçmişini korumayı kolaylaştırır. Çekme istekleri veya derleme geçmişi gibi diğer geçmişler kolayca geçirilmez.

Bir veya birden çok depo için kararınızı aşağıdaki faktörlere ve ipuçlarına dayandırın:

  • kod bağımlılıkları ve mimarisi
  • bağımsız olarak dağıtabilen her ürünü veya hizmeti kendi deposuna yerleştirme
  • kod tabanını, bu depolar arasında eşgüdümlü kod değişiklikleri yapmayı düşünüyorsanız birçok depoya ayırmayın çünkü hiçbir araç bu değişiklikleri koordine etmeye yardımcı olamaz
  • kod tabanınız zaten bir monolith ise, bunu tek bir depoda tutun. Monolitik depolar hakkında daha fazla bilgi için bkz . Microsoft DevOps ile modern yazılımları nasıl geliştirir?
  • bağlantısı kesilmiş birçok hizmetiniz varsa, hizmet başına bir depo iyi bir stratejidir

İpucu

Kuruluşunuzdaki herkesin depo oluşturabilmesi için izinlerinizi yönetmeyi göz önünde bulundurun. Çok fazla deponuz varsa, bu depolarda depolanan kodun veya diğer içeriğin sahibini takip etmek zordur.

Paylaşılan depo ile çatallanmış depo karşılaştırması

Güvenilir bir kuruluş içinde paylaşılan bir depo kullanmanızı öneririz. Geliştiriciler, değişikliklerini birbirinden yalıtmak için dalları kullanır. İyi bir dallanma ve sürüm stratejisiyle tek bir depo, binden fazla geliştirici için eşzamanlı geliştirmeyi destekleyecek şekilde ölçeklendirilebilir. Dallanma ve sürüm stratejisi hakkında daha fazla bilgi için bkz . Git dallanma stratejisini benimseme ve Yayın Akışı: Dallanma Stratejimiz.

Çatallar, ana depoyu güncelleştirmek için doğrudan erişimi olmaması gereken satıcı ekipleriyle çalışırken yararlı olabilir. Çatallar, açık kaynak bir projede olduğu gibi birçok geliştiricinin seyrek katkıda bulunduğu senaryolarda da yararlı olabilir. Çatallarla çalışırken, çatallanmış depoları ana depodan yalıtmak için ayrı bir proje tutmak isteyebilirsiniz. Ek yönetim yükü olabilir, ancak ana projeyi daha temiz tutar. Daha fazla bilgi için Çatallar makalesine bakın.

Aşağıdaki görüntüde , "şirketinizin" kuruluşlarını, projelerini, iş öğelerini, ekiplerini ve depolarını nasıl yapılandırabileceğine ilişkin bir örnek gösterilir.

Bir şirketin kuruluş yapısını gösteren diyagram.

Kuruluş yapısı hakkında daha fazla bilgi

Kuruluşunuzun yönetici hesap türünü seçin

Bir kuruluş oluşturduğunuzda, oturum açmak için kullandığınız kimlik bilgileri kuruluşunuzun hangi kimlik sağlayıcısını kullandığını tanımlar. Bir Microsoft hesabı veya Microsoft Entra örneği ile kuruluşunuzu oluşturun. adresinde yeni kuruluşunuzda https://dev.azure.com/{YourOrganization}yönetici olarak oturum açmak için bu kimlik bilgilerini kullanın.

Microsoft hesabınızı kullanma

Microsoft Entra Id ile bir kuruluş için kullanıcıların kimliğini doğrulamanız gerekmiyorsa Microsoft hesabınızı kullanın. Tüm kullanıcıların kuruluşunuzda bir Microsoft hesabıyla oturum açması gerekir. Hesabınız yoksa bir Microsoft hesabı oluşturun.

Parolanızı girin ve oturum açın

Microsoft Entra örneğiniz yoksa Azure portalından ücretsiz olarak bir örnek oluşturun veya Microsoft hesabınızı kullanarak kuruluş oluşturun. Ardından, kuruluşunuzu Microsoft Entra Id'ye bağlayabilirsiniz.

Microsoft Entra hesabınızı kullanma

Azure veya Microsoft 365 kullanıyorsanız zaten bir Microsoft Entra hesabınız olabilir. Kullanıcı izinlerini yönetmek için Microsoft Entra Id kullanan bir şirkette çalışıyorsanız, büyük olasılıkla bir Microsoft Entra hesabınız vardır.

Microsoft Entra hesabınız yoksa, kuruluşunuzu Microsoft Entra Id'nize otomatik olarak bağlamak için Microsoft Entra Id'ye kaydolun. Kuruluşunuza erişmek için tüm kullanıcıların bu dizine üye olması gerekir. Diğer kuruluşlardan kullanıcı eklemek için Microsoft Entra B2B işbirliğini kullanın.

Azure DevOps, microsoft Entra kimliğiniz aracılığıyla kullanıcıların kimliğini doğrular, böylece yalnızca bu dizine üye olan kullanıcılar kuruluşunuza erişebilir. Kullanıcıları bu dizinden kaldırdığınızda, artık kuruluşunuza erişemezler. Yalnızca belirli Microsoft Entra yöneticileri dizininizdeki kullanıcıları yönetir, bu nedenle yöneticiler kuruluşunuza kimlerin erişeceklerini denetler.

Kullanıcıları yönetme hakkında daha fazla bilgi için bkz . Kullanıcıları yönetme.

Kuruluşları iş birimleriyle eşleme

Şirketinizdeki her iş birimi, Azure DevOps'ta kendi kuruluşuna ve kendi Microsoft Entra kiracısına sahip olur. Gerektiğinde, ekiplere veya devam eden çalışmalara dayalı olarak, bu tek tek kuruluşlar içinde projeler ayarlayabilirsiniz.

Daha büyük bir şirket için, farklı kullanıcı hesapları (büyük olasılıkla Microsoft Entra hesapları) kullanarak birden çok kuruluş oluşturabilirsiniz. Grupların ve kullanıcıların hangi stratejileri paylaştığını ve hangilerinin çalıştığını göz önünde bulundurun ve bunları belirli kuruluşlar halinde gruplandırma.

Örneğin, kurgusal Fabrikam şirketi aşağıdaki üç kuruluşu oluşturmuştur:

  • Fabrikam-Marketing
  • Fabrikam-Mühendislik
  • Fabrikam-Sales

Her kuruluşun ayrı bir URL'si vardır, örneğin:

  • https://dev.azure.com/Fabrikam-Marketing
  • https://dev.azure.com/Fabrikam-Engineering
  • https://dev.azure.com/Fabrikam-Sales

Kuruluşlar aynı şirkete yöneliktir, ancak çoğunlukla birbirinden yalıtılmış durumdadır. Hiçbir şeyi bu şekilde ayırmanız gerekmez. Yalnızca işiniz için anlamlı olduğunda sınırlar oluşturun.

İpucu

Mevcut bir kuruluşu farklı kuruluşları birleştirmekten daha kolay bir şekilde projelerle bölümleyebilirsiniz.