Yazılım mühendisliği sistemlerini uygulama

Makale
07/23/2024

Geliştirici self servisini geliştirmek, platform mühendisliği yolculuğunuzda ilk karşılaştığınız sorunlardan biri olmalıdır.

Otomatik self servis deneyimlerini etkinleştirmeye başlamanın en kolay yollarından biri, mevcut mühendislik sistemlerinizi yeniden kullanmaktır. Bu sistemler yalnızca size ve şirket içi müşterilerinize tanıdık olmakla kalmaz, aynı zamanda ilk kullanıcı deneyimi hoş olmasa bile çok çeşitli otomasyon senaryolarını etkinleştirebilir.

Bu makale, daha geniş bir self servis senaryoları dizisiyle başa çıkmak için mühendislik sistemlerinizi uygulamaya yönelik ipuçları ve doğru başlangıç ve doğru şekilde çalışmaya başlamanıza yardımcı olacak şablonlara en iyi yöntemleri kapsülleme hakkında ayrıntılı bilgi sağlar.

Temel DevOps ve DevSecOps uygulamalarınızı değerlendirme

Mühendislik sistemleri, iç geliştirici platformunuzun kritik bir yönüdür. İç geliştirici platformları, ilgili herkesin bilişsel yükünü azaltmak için DevOps ve DevSecOps'un ana kiracılarından oluşturulur.

DevOps, uygulama planlama, geliştirme, teslim ve operasyonlardaki kişileri, süreci ve teknolojiyi birleştirmek için geliştirme ve işlemleri birleştirir. Geliştirme, BT operasyonları, kalite mühendisliği ve güvenlik gibi geçmişe dönük silolu roller arasında işbirliğini geliştirmeyi amaçlar. Geliştirme, dağıtım, izleme, gözlem ve geri bildirim arasında sürekli bir döngü oluşturursunuz. DevSecOps, uygulama geliştirme süreci boyunca sürekli güvenlik uygulamalarıyla bu döngüye katman ekler.

Plan, teslim, geliştirme, çalıştırma ile DevOps yaşam döngüsünün görüntüsü.

Aşağıdaki bölümlerde platform mühendisliği hareketine daha doğrudan atfedilen iyileştirmeler ele alınıyor: yol açılan yollar, otomatik altyapı sağlama (uygulama dağıtımına ek olarak), kodlama ortamı kurulumu, self servis sağlama ve uygulama geliştirme döngüsünün doğrudan bir parçası olmayan araçların, ekip varlıklarının ve hizmetlerin yapılandırılması.

İstediğiniz döşeli yolları oluşturun

Mühendislik sistemlerinizi oluşturan birden çok araç kümeniz varsa, ilk kararlardan biri, bunları ilk platform mühendislik çalışmalarınızın bir parçası olarak birleştirmek mi istediğiniz yoksa başlangıçtan itibaren farklı araçların takımyıldızını destekleyip desteklemeyeceksiniz. Bu takımyıldızı takımyıldızı içinde bir dizi yol tanımlamak en etkili olandır ve daha fazla esneklik sağlar.

Bir ürün zihniyetine doğru geçiş yapmaya başladığınızda, bu döşeli yollar içindeki mühendislik sistemlerini geliştirme ekiplerine bir hizmet olarak merkezi olarak yönetilen araçlardan oluşan araçlar olarak düşünün. Daha sonra kuruluşunuzdaki tek tek ekipler veya bölümler sapmaya devam edebilir ancak uyumluluk gereksinimlerine uymaya devam ederken araçlarını ayrı ayrı yönetmesi, koruması ve ödemesi beklenir. Bu, zaman içinde kaldırımlı bir yola olası bir ekleme için sapma gösteren her şeyi değerlendirebildiğiniz için ekosisteme yeni araçlar beslemek için bir yol sağlar. Tek bir platform mühendisliği liderinin belirttiği gibi:

Yine de kendi işlerinizi yapabilirsiniz, ancak gittiğimiz yönde yapabilirsiniz... ne isterseniz değiştirebilirsiniz, ancak bu sizin sorumluluğunuzdadır. Değişikliklerin sahibi sizsiniz– keskin bıçakların sahibi sizsiniz. - Mark, platform mühendisliği lideri, Büyük Avrupa Çok Uluslu Perakende Şirketi

Platform mühendisliği için önemli bir hedefin, şirket içi müşterilerinize değer verdiğiniz bir ürün anlayışına geçmek olduğu düşünüldüğünde, bu kümeleme yaklaşımı genellikle yukarıdan aşağıya görevden daha iyi çalışır. Siz yollarınızı oluşturup iyileştirdikçe, bazı esneklikler bırakmak ekiplerin kuruluştaki diğer kişileri etkilemeden belirli bir uygulama için gerçekten benzersiz gereksinimleri sağlamasına ve karşılamasına olanak tanır. Bu, tamamen döşeli, altın renkli bir yol kümesine yol açarken, diğerleri yalnızca kısmen döşeniyor. Benzersiz gereksinimlerin olmadığı durumlarda, ek iş geliştirme ekipleri doğal olarak zaman içinde desteklenen bir yola geçmek istemelerine neden olur.

Birleştirme stratejisini tercih ediyorsanız, mevcut uygulamaları geçirmek beklediğinizden daha fazla iş olabilir, bu nedenle başlamak için büyük olasılıkla bu alanın doğru başlangıç yönüne odaklanmak ve yeni projelere odaklanmak istersiniz. Bu size ilk yolunuzu sağlarken, var olan her şey doğal olarak kaydedilmemiş durumdadır. Daha sonra, yeni yolunuzun kuruluşa değerini gösterdiğinde, kaydedilmemiş yoldaki geliştirme ekipleri ilerlemeyi göz önünde bulunduracaktır. Bu noktada, geliştirme ekipleri bunu vergi yerine avantaj olarak görüntülediğinden, iki yönlü iletişim yoluyla herkesin istediğiniz duruma ulaşabilmesi için doğru bir get kampanyası yürütebilirsiniz. Kampanya sırasında platform mühendisliği ekipleri ekiplerin geçişine yardımcı olmaya odaklanabilirken, geliştirme ekipleri de yollara nasıl daha iyi gidebilecekleri konusunda geri bildirimde bulunabilir.

Ne olursa olsun, yollarınızın kullanımını mandating kaçının. Döşenmiş yolların piyasaya sürülmesinin en etkili yolu, ekiplerin zorla benimseme yoluyla değil, onlardan ne elde ettiğinizi vurgulamadır. İç geliştirici platformunuz bu tam olarak aynı ekipleri mutlu etmeye odaklandığından, gerisini tek tek liderler üzerinde bütçe ve değer baskısı üstlenir. Doğru kampanyaları alın ve ardından en iyi şekilde iki yönlü konuşmalar için bir yol sunun.

Yollarınızın self servisini geliştirmek için geliştirici otomasyon araçlarını kullanma

İlk yolunuzu oluşturmanın bir parçası, temel geliştirici otomasyon ürünlerinizi oluşturmak olmalıdır. Geliştirici self servis özelliklerini etkinleştirmeyi düşünmeye başladığınızda bunlar önemlidir.

Sürekli teslim sırasında otomatik uygulama altyapısı sağlamayı etkinleştirme

Henüz uygulanmadıysa, planlamanız sırasında tanımladığınız sorunlar büyük olasılıkla sürekli tümleştirme (CI) ve sürekli teslim (CD) sorunlarının çözülmesine yardımcı olabilir. GitHub Actions, Azure DevOps , Jenkins gibi ürünlerin yanı sıra Flux veya Argo CD gibi çekme tabanlı GitOps çözümleri de bu alanda mevcuttur. Bu konulara Microsoft DevOps kaynak merkezinden başlayabilirsiniz.

Uygulamanızı mevcut altyapıya sürekli olarak dağıtmanın bir yolunu zaten uygulamış olsanız bile, GEREKLI uygulama altyapısını CD işlem hattınızın bir parçası olarak oluşturmak veya güncelleştirmek için kod olarak altyapıyı (IaC) kullanmayı düşünmelisiniz.

Örneğin, altyapıyı güncelleştirmek ve Azure Kubernetes Service'e dağıtmak için GitHub Actions kullanan iki yaklaşımı gösteren şu çizimleri göz önünde bulundurun: biri gönderim tabanlı dağıtımları ve biri çekme tabanlı (GitOps) dağıtımları kullanmak.

Seçtiğiniz, mevcut IaC beceri kümeniz ve hedef uygulama platformunuzun ayrıntıları tarafından yönlendirilir. GitOps yaklaşımı daha yenidir ve uygulamaları için temel olarak Kubernetes kullanan kuruluşlar arasında popülerdir, ancak çekme tabanlı model şu anda kullanılabilir seçenek sayısı göz önünde bulundurulduğunda size en fazla esnekliği sağlar. Çoğu kuruluşun ikisinin bir karışımını kullanmasını bekliyoruz. Ne olursa olsun, IaC uygulamalarında iyi bilgi sahibi olmak, daha fazla otomasyon senaryoları için geçerli olan desenleri öğrenmenize yardımcı olur.

Güvenliği ölçeklendirmek ve geliştirmek için bir katalog veya kayıt defterinde IaC'yi merkezileştirme

IaC'yi uygulamalar arasında yönetmek ve ölçeklendirmek için IaC yapıtlarınızı yeniden kullanmak üzere merkezi olarak yayımlamanız gerekir. Örneğin Terraform modüllerini bir kayıt defterinde, Bicep modüllerinde, Radius tariflerinde veya Azure Container Registry (ACR), DockerHub gibi bir bulutta yerel OCI Artifact kayıt defterinde veya Azure Dağıtım Ortamları'ndaki (ADE) katalogda depolanan Helm Grafiklerinde kullanabilirsiniz. GitOps ve Kubernetes için Küme API'si (ve CAPZ gibi uygulamalar), Kubernetes iş yükü kümelerini yönetmenize olanak sağlarken, Azure Hizmet Operatörü gibi özel kaynak tanımları diğer azure kaynakları türleri için ek destek sağlayabilir ve Çapraz düzlem gibi diğer araçlar birden çok bulutta kaynakları destekler. Bunlar, daha geniş bir senaryo dizisi için ACR gibi bir şeyde merkezi veya ortak Helm grafiklerini kullanmanıza olanak sağlar.

IaC'yi merkezi hale getirmek, artık uygulama koduyla depolanmadığından güncelleştirmeleri kimlerin gerçekleştirebileceği üzerinde daha iyi denetim sahibi olmanıza yardımcı olarak güvenliği artırır. Uzmanlar, operasyonlar veya platform mühendislerinin gerekli değişiklikleri yaptığı bir kod güncelleştirmesi sırasında yanlışlıkla yapılan bir değişikliğin neden olduğu yanlışlıkla kırılma riski daha azdır. Geliştiriciler ayrıca tam IaC şablonlarını kendileri yazmaları ve kodlanmış en iyi uygulamalardan otomatik olarak yararlanmaları gerekmeyen bu yapı taşları avantajından da yararlanır.

Seçtiğiniz IaC biçimi mevcut beceri kümenize, ihtiyacınız olan denetim düzeyine ve kullandığınız uygulama modeline bağlıdır. Örneğin Azure Container Apps (ACA) ve son deneysel Radius OSS kuluçka projesi, Kubernetes'i doğrudan kullanmaya kıyasla daha fazla fikir edinmekle birlikte geliştirici deneyimini kolaylaştırmaktadır. Bulut hizmeti türlerini açıklama eğitim modülü, farklı modellerin olumlu ve dezavantajlarını anlamanıza yardımcı olabilir. Ne olursa olsun, kaynak ağacınızda tam tanımlara sahip olmak yerine merkezi ve yönetilen IaC'ye başvurmanın önemli avantajları vardır.

Geliştiricilerin idare için temel yapı taşları içindeki katmanlara doğrudan erişemeyecek şekilde gerekli sağlama kimliklerini veya gizli dizilerini kalıcı hale getirebilirsiniz. Örneğin, Azure Dağıtım Ortamları 'nı (ADE) kullanarak başarabileceğiniz rol ayrımı ile ilgili bu çizimi göz önünde bulundurun.

Burada, platform mühendisleri ve diğer uzmanlar IaC ve diğer şablonları geliştirir ve bunları bir kataloğa yerleştirir. İşlemler daha sonra yönetilen kimlikleri ve abonelikleri "ortam türüne" göre ekleyebilir ve sağlama için bunları kullanmasına izin verilen geliştiricilere ve diğer kullanıcılara atayabilir.

Geliştiriciler veya CI/CD işlem hattınız daha sonra Azure CLI'yi veya Azure Geliştirici CLI'sini kullanarak, temel alınan aboneliğe veya bunu yapmak için gereken kimliklere bile erişime gerek kalmadan önceden yapılandırılmış ve denetimli altyapı sağlayabilir. ADE gibi bir şey kullansanız da kullanmasanız da tercih ettiğiniz sürekli teslim sisteminiz, geliştiricilerin kendi kendilerine erişemeyeceği veya değiştiremeyeceği konumlardan gizli dizileri ayırıp IaC içeriğini kaynak oluşturarak altyapıyı güvenli ve güvenli bir şekilde güncelleştirmenize yardımcı olabilir.

Uygulama sürekli teslimi dışındaki senaryolarda self servis özelliğini etkinleştirme

CI ve CD kavramları uygulama geliştirmeye bağlı olsa da, iç müşterilerinizin sağlamak istediği birçok şey doğrudan belirli bir uygulamayla ilgili değildir. Bu, paylaşılan altyapı, depo oluşturma, sağlama araçları ve daha fazlası olabilir.

Bunun nerede yardımcı olabileceğini anlamak için şu anda el ile veya hizmet masası tabanlı işlemlere sahip olduğunuz yeri düşünün. Her bir soru için şu soruları düşünün:

Bu işlem ne sıklıkta gerçekleşir?
İşlem yavaş mı, hataya açık mı yoksa ulaşmak için önemli bir çalışma mı gerektiriyor?
Bu işlemler gerekli bir onay adımından mı yoksa yalnızca otomasyon eksikliğinden mi dolayı el ile gerçekleştirilir?
Onaylayanlar kaynak denetim sistemleri ve çekme isteği işlemleri hakkında bilgi sahibi mi?
İşlemler için denetim gereksinimleri nelerdir? Bunlar kaynak denetim sisteminizin denetim gereksinimlerinden farklı mı?
Daha karmaşık işlemlere geçmeden önce daha düşük riskle başlayabileceğiniz işlemler var mı?

Sık, yüksek çaba veya hataya açık işlemleri ilk olarak otomatikleştirmeye yönelik olası hedefler olarak belirleyin.

Her şeyi kod deseni olarak kullanma

Git'in yaygınlığına ek olarak en güzel özelliklerinden biri, güvenli ve denetlenebilir bir bilgi kaynağı olmasıdır. İşleme geçmişi ve erişim denetimlerinin ötesinde, çekme istekleri ve dal koruması gibi kavramlar, ana dala birleştirmeden önce geçmesi gereken belirli gözden geçirenler, konuşma geçmişi ve veya otomatik denetimler oluşturmanın bir yolunu sağlar. CI/CD sistemlerinde bulunanlar gibi esnek görev altyapılarıyla birleştirildiğinde, güvenli bir otomasyon çerçevesine sahip olursunuz.

Kod olarak her şeyin ardındaki fikir, güvenli bir git deposunda neredeyse her şeyi bir dosyaya dönüştürebilmenizdir. Ardından depoya bağlı farklı araçlar veya aracılar içeriği okuyabilir. Şablon oluşturma ve geliştirici self servis işlemlerini basitleştirme yoluyla her şeyi kod olarak tekrarlanabilirlik olarak ele almak. Şimdi bunun nasıl çalışabileceğine birkaç örnek inceleyelim.

Herhangi bir altyapıya IaC desenleri uygulama

IaC, uygulama teslimini otomatikleştirmeye yardımcı olma konusunda popülerlik kazansa da, desen yalnızca belirli bir uygulamaya bağlı olanlar için değil, sağlamak ve yapılandırmak isteyebileceğiniz tüm altyapılara, araçlara veya hizmetlere genişletilir. Örneğin, Flux yüklü kümelerle paylaşılan K8'ler, birden çok ekip ve uygulama tarafından kullanılan DataDog gibi bir şey sağlama ve hatta sık kullandığınız işbirliği araçlarını ayarlama.

Bunun işe yaraması için, nelerin sağlanması ve yapılandırılması gerektiğini (bu örnekte Bicep, Terraform, Helm grafiklerinden Helm grafikleri ve diğer Kubernetes yerel biçimlerine kadar her şeyi) temsil eden bir dizi dosyanın barındırıldığı ayrı ve güvenli bir merkezi deponuz olmasıdır. Deponun sahibi bir operasyon ekibi veya diğer yönetici kümesidir ve geliştiriciler (veya sistemler) çekme istekleri gönderebilir. Bu PR'ler bu yöneticiler tarafından ana dalda birleştirildikten sonra, uygulama geliştirme sırasında kullanılan CI/CD araçları değişiklikleri işlemek için devreye girer. Azure Dağıtım Ortamlarında yer alan GitHub Actions, IaC ve dağıtım kimliklerini kullanan bu çizimi göz önünde bulundurun:

Uygulama dağıtımı için zaten bir GitOps yaklaşımı kullanıyorsanız, bu araçları da yeniden kullanabilirsiniz. Flux ve Azure Hizmet Operatörü gibi araçları birleştirmek Kubernetes'in dışına genişletmenizi sağlar:

Her iki durumda da, bir uygulama için üretilenler olmasa bile, tam olarak yönetilen, yeniden üretilebilir ve denetlenebilir bir bilgi kaynağınız vardır. Uygulama geliştirmede olduğu gibi, ihtiyacınız olan tüm gizli diziler veya yönetilen kimlikler işlem hattında/iş akışı altyapısında veya sağlama hizmetinin yerel özelliklerinde depolanır.

PR'leri oluşturan kişilerin bu gizli dizilere doğrudan erişimi olmayacağından, geliştiricilerin kendileri için doğrudan izni olmayan eylemleri güvenli bir şekilde başlatması için bir yol sağlar. Bu, geliştiricilere bir self servis seçeneği sağlarken en az ayrıcalık ilkesine bağlı kalmanızı sağlar.

Sağlanan altyapıyı izleme

Bu yaklaşımı ölçeklendirmeye başladığınızda, sağlanan altyapıyı nasıl izlemek istediğinizi düşünün. Git deponuz yapılandırma için doğru bir kaynaktır, ancak oluşturduğunuz URI'leri ve durum bilgilerini size söylemez. Ancak her şeyi kod olarak uygulamak, sağlanan altyapı envanterini sentezlemek için size bağlanabileceğiniz bir bilgi kaynağı sağlar. Sağlama sağlayıcınız, bu bilgilere dokunabileceğiniz iyi bir kaynak olabilir. Örneğin Azure Dağıtım Ortamları, geliştiricilerin görünürlüğüne sahip olduğu ortam izleme özelliklerini içerir.

Çeşitli veri kaynakları arasında izleme hakkında daha fazla bilgi edinmek için bkz . Geliştirici self servis temeli tasarlama.

Güvenliği kod olarak ve ilkeyi kod desenleri olarak uygulama

Altyapı sağlamak yararlı olsa da, bu ortamların güvenli olduğundan ve genellikle kuruluşunuzun ilkelerine uygun olduğundan emin olmak da aynı derecede önemlidir. Bu, "kod olarak ilke" kavramının artmasına yol açmıştır. Burada, bir kaynak denetimi deposundaki yapılandırma dosyaları, güvenlik taramasını yönlendirme veya altyapı ilkelerini uygulama gibi işlemler yapmak için kullanılabilir.

Azure İlkesi, Open Policy Agent , GitHub Advanced Security ve GitHub CODEOWNERS gibi birçok farklı ürün ve açık kaynak projesi bu yaklaşımı desteklemiştir. Uygulama altyapınızı, hizmetlerinizi veya araçlarınızı seçerken bu desenleri ne kadar iyi desteklediklerini değerlendirdiğinizden emin olun. Uygulamanızı ve idarenizi iyileştirme hakkında daha fazla bilgi için bkz . Uygulama platformunuzu iyileştirme.

Her şeyi kendi senaryolarınız için kod olarak kullanın

Kod olarak her şey bu desenleri IaC'nin ötesinde çok çeşitli otomasyon ve yapılandırma görevlerine genişletir. Yalnızca herhangi bir altyapı türü oluşturmayı veya yapılandırmayı değil, aynı zamanda herhangi bir aşağı akış sisteminde verileri güncelleştirmeyi veya iş akışlarını tetiklemesini de destekleyebilir.

Çekme isteği, özellikle de başlarken çeşitli işlemler için iyi bir temel self servis kullanıcı deneyimi haline gelir. İşlemler doğal olarak Git'in sağladığı güvenlik, denetlenebilirlik ve geri alma avantajlarını elde eder ve dahil olan sistemler de kullanıcı deneyimini etkilemeden zaman içinde değişebilir.

Kod olarak Teams

Her şeyi kendi senaryolarınıza kod olarak uygulamanın bir örneği, ekiplerin kod deseni olarak uygulanmasıdır. Kuruluşlar, ekip üyeliğini ve bazı durumlarda çok çeşitli sistemlerde geliştirici araçları/hizmet yetkilendirmelerini standartlaştırmak için bu düzeni uygular. Bu düzen, sistem geliştiricilerinin ve operatörlerinin kendi gruplandırma, kullanıcı ve erişim kavramlarına erişme gereksiniminden kaynaklanan el ile ekleme ve çıkarma hizmet masası işlemlerini ortadan kaldırır. El ile hizmet masaları işlemleri, erişimin fazla sağlanması mümkün olduğundan olası bir güvenlik riskidir. Ekipleri kod deseni olarak kullanırken git ve çekme isteklerinin birleşimi denetlenebilir bir veri kaynağından self servis sağlayabilir.

Bu desenin olgun ve kapsamlı bir varyasyonu için Yetkilendirmeleri nasıl yönettiklerine ilişkin GitHub'ın blog gönderisine göz atın. GitHub ayrıca, denemeniz veya benimsemeniz için gelişmiş Yetkilendirmeler uygulamasını açık kaynaklı olarak sunar. Blog gönderisinde tüm çalışan yetkilendirmeleri açıklansa da, ekipleri daha dar kapsamlı geliştirme ekibi senaryolarına kod kavramı olarak uygulayabilirsiniz. Bu geliştirme ekipleri bir çalışan kuruluş şemasında temsil edilmeyebilir ve ekip üyelerini ekleme veya çıkarma konusunda karmaşık hale gelebilen özel araçlar veya hizmetler içerebilir.

Güncelleştirmeleri koordine etmek için CI/CD sistemi ve kimlik sağlayıcısı grupları kullanan bu fikrin basitleştirilmiş bir varyasyonunun özeti aşağıdadır:

Bu örnekte:

İlgili her sistem, çoklu oturum açma (SSO) için kimlik sağlayıcınızı (örneğin, Microsoft Entra Id) kullanacak şekilde ayarlanmıştır.
Karmaşıklığı azaltmak ve merkezi denetimi sürdürmek için üyelikleri role göre yönetmek için sistemler arasında kimlik sağlayıcısı gruplarını (örneğin, Entra grupları) kullanacaksınız.

Üst düzeyde, bu desen şu şekilde çalışır:

Merkezi, kilitli git deposunda her soyut ekibi, ilgili kullanıcı üyeliğini ve kullanıcı rollerini temsil eden bir dizi (genellikle YAML) dosyası vardır. Ekip değişikliklerinin sahipleri veya onaylayanları da aynı yerde depolanabilir (örneğin, CODEOWNERS aracılığıyla). Bu dosyalardaki bir kullanıcıya başvuru, kimlik sağlayıcısıdır, ancak bu depo bu ekiplerin (kullanıcılar için değil) gerçek kaynağı olarak hareket eder.
Bu dosyalarda yapılan tüm güncelleştirmeler çekme istekleri aracılığıyla gerçekleştirilir. Bu, konuşmaları ve ilgili katılımcıları denetlenebilirlik için git işleme isteğine bağlar.
Müşteri adayları ve tek tek kullanıcılar kişi eklemek/kaldırmak için PR oluşturabilir ve müşteri adayları ile diğer roller şablondan yeni bir ekip dosyası içeren ÇEKME'leri kullanarak yeni ekipler oluşturabilir.
Bir çekme isteği main ile birleştirildiğinde, depoya bağlı bir CI/CD sistemi kimlik sağlayıcısı sistemini ve tüm aşağı akış sistemlerini uygun şekilde güncelleştirir.

Özellikle, CI/CD sistemi:

Rol başına bir kimlik sağlayıcısı grubu oluşturmak veya dosyadaki bireylerle güncelleştirmek için uygun kimlik sağlayıcısı sistem API'sini kullanır (artık, daha az değil).
Her aşağı akış sistemi için API'leri kullanarak bu sistemler gruplandırma kavramını her rol için tanımlayıcı sağlayıcı gruplarına bağlar (örneğin: GitHub ve Azure DevOps). Bu, bir rolü temsil etmek için ekibinizle aşağı akış sistemi arasında bire çok ilişkisine neden olabilir.
(İsteğe bağlı olarak) Sistemin gruplandırma mekanizmasına bağlı izin mantığını uygulamak için her aşağı akış sistemi için API'leri kullanır.
Kilitli bir veri deposunu, daha sonra dahili olarak derlenmiş sistemlerinizden herhangi biri için kullanılabilecek sonuçlarla (aşağı akış sistemi ekip kimliklerini ilişkilendirme dahil) güncelleştirmek için BIR API kullanır. Gerekirse, aynı kimlik sağlayıcısı kullanıcısı/hesabı için kullanıcı kimliklerinin farklı sistem gösterimleri için ilişkilendirmeleri de burada depolayabilirsiniz.

Kuruluşunuz zaten Entra Yetkilendirme Yönetimi gibi bir şey kullanıyorsa, bu düzenden grup üyeliğini yönetmeyi atlayabilirsiniz.

gereksinimleriniz ve ilkeleriniz ayrıntıları değiştirebilir, ancak genel desen herhangi bir sayıda varyasyona uyarlanabilir. Herhangi bir aşağı akış sistemiyle tümleştirmek için gereken gizli diziler CI/CD sisteminde (örneğin GitHub Actions,Azure Pipelines) veya Azure Key Vault gibi bir sistemde tutulur.

El ile veya dışarıdan tetiklenen, parametreli iş akışlarını kullanma

Tanımladığınız self servisle ilgili sorunlardan bazıları Git'te dosyaları kullanmaya yardımcı olmayabilir. Alternatif olarak, self servis deneyimini yönlendirmek için kullanmak istediğiniz bir kullanıcı arabirimine sahip olabilirsiniz.

Neyse ki GitHub Actions ve Azure Pipelines da dahil olmak üzere çoğu CI sistemi, girişlerle bir iş akışı ayarlama özelliğine sahiptir ve bu iş akışını kendi UI'leri veya CLI'leri aracılığıyla el ile tetikleyebilirsiniz. Geliştiriciler ve ilgili operasyon rolleri büyük olasılıkla bu kullanıcı deneyimlerini zaten biliyorsa, el ile tetikleyiciler doğal bir dosya gösterimi olmayan veya çekme isteği işlemi gerektirmeden tamamen otomatikleştirilmesi gereken etkinliklerde (veya işlerde) otomasyonu etkinleştirmek üzere kod deseni olarak her şeyi genişletebilir.

CI sisteminiz, bir API aracılığıyla kendi kullanıcı deneyimlerinizden bu iş akışlarını veya işlem hatlarını tetiklemenizi seçebilir. GitHub Actions için bu işi yapmanın anahtarı, bir iş akışı çalıştırmasını tetikleyen bir iş akışı dağıtım olayını tetikleyen Eylemler REST API'leridir. Azure DevOps tetikleyicileri benzerdir ve çalıştırmalar için Azure DevOps Pipeline API'sini de kullanabilirsiniz. Büyük olasılıkla diğer ürünlerde de aynı özellikleri görürsünüz. İster el ile ister bir API aracılığıyla tetiklensin, her iş akışı iş akışı YAML dosyasına bir workflow_dispatch yapılandırması ekleyerek bir dizi girişi destekleyebilir. Örneğin, Backstage.io gibi portal araç setleri GitHub Actions ile bu şekilde etkileşim kurar .

CI/CD sisteminizin iş akışı veya iş sistemi şüphesiz etkinlikleri izler, durumu geri bildirir ve hem geliştiricilerin hem de operasyon ekiplerinin neyin yanlış gittiğini görmek için kullanabileceği ayrıntılı günlüklere sahiptir. Bu şekilde, kod deseni olarak her şey ile aynı güvenlik, denetlenebilirlik ve görünürlük avantajlarından bazılarına sahiptir. Bununla birlikte, bu iş akışları veya işlem hatları tarafından gerçekleştirilen tüm eylemlerin aşağı akış sistemlerine sistem kimliği (örneğin, Hizmet Sorumlusu veya Microsoft Entra Id'de yönetilen kimlik) gibi görünmesi de göz önünde bulundurulması gerekir.

CI/CD sisteminizde istekleri kimin başlattığına ilişkin görünürlüğe sahip olursunuz, ancak bunun yeterli bilgi olup olmadığını değerlendirmeli ve CI/CD saklama ayarlarınızın bu bilgilerin kritik olduğu durumlar için denetim gereksinimlerinizle uyumlu olduğundan emin olmalısınız.

Diğer durumlarda, tümleştirdiğiniz araçların güvenebileceğiniz kendi izleme mekanizmaları olabilir. Örneğin, bu CI/CD araçlarının hemen her zaman Microsoft Teams veya Slack kanalı kullanma gibi çeşitli bildirim mekanizmaları vardır. Bu mekanizmalar durum güncelleştirmelerini almak için istek gönderen herkesi tutmanıza olanak tanır ve kanal ne olduğuna dair resmi olmayan bir kayıt sağlar. Aynı iş akışı altyapıları genellikle bu desenlerin kullanışlılığını daha da genişletmek için operasyon araçlarıyla tümleştirmek üzere tasarlanmıştır.

Özetle, CI/CD araçlarının esnekliği ve kullanıma sunulan kullanıcı deneyimleri sayesinde kaynak denetim deposunda depolanan dosyaları kullanarak bazı otomasyonlar uygulayabilirsiniz. İç geliştirici platformlarının zaman içinde daha gelişmiş özelliklerden ödün vermeden bu yaklaşımı başlangıç noktası olarak nasıl kullanabileceğini görmek için bkz . Geliştirici self servis temeli tasarlama.

Geliştirici kodlama ortamlarının kurulumunu otomatikleştirme

Mühendislik sistemlerindeki bir diğer yaygın sorun da geliştirici kodlama ortamı önyükleme ve normalleştirmedir. Bu alanda duyabileceğiniz yaygın sorunlardan bazıları şunlardır:

Bazı durumlarda, bir geliştiricinin ilk çekme isteğine ulaşabilmesi haftalar sürebilir. Bu, geliştiricileri özellik ekipleri ve projeler arasında oldukça sık aktardığınızda (örneğin, matrisli kuruluşlarda), yüklenicileri artırmanız gerektiğinde veya işe alma aşamasında olan bir ekipte olduğunuzda sorunlu bir alandır.
Geliştiricilerle CI sistemleriniz arasındaki tutarsızlık, deneyimli ekip üyeleri için bile sık sık "makinemde çalışıyor" sorunlarına yol açabilir.
Denemeler ve yükseltme çerçeveleri, çalışma süreleri ve diğer yazılımlar da mevcut geliştirici ortamlarını bozabilir ve tam olarak neyin yanlış gittiğini anlamaya çalışırken zaman kaybına neden olabilir.
Geliştirme müşteri adayları için kod incelemeleri, gözden geçirme tamamlandıktan sonra test etmek ve geri almak için bir yapılandırma değişikliği gerektirebileceği için geliştirmeyi yavaşlatabilir.
Ekip üyelerinin ve operatörlerin, ilerlemeyi test etmeye, ilerlemeyi görmeye, iş rollerini eğitmeye ve ekibin yaptığı işi yaygınlaştırmaya yardımcı olmak için geliştirmenin ötesinde ilgili rolleri (operatörler, Soru-Cevap, iş, sponsorlar) artırmaya da zaman harcamaları gerekir.

Yollarınızın bir bölümü

Bu sorunların çözülmesine yardımcı olmak için, iyi tanımlanmış yollarınızın bir parçası olarak belirli araçların ve yardımcı programların kurulumunu düşünün. Betik oluşturma geliştirici makinesi kurulumu yardımcı olabilir ve bu betikleri CI ortamınızda yeniden kullanabilirsiniz. Ancak, sağlayabilecekleri avantajlar nedeniyle kapsayıcılı veya sanallaştırılmış geliştirme ortamlarını desteklemeyi göz önünde bulundurun. Bu kodlama ortamları, kuruluşunuzun veya projenizin belirtimlerine önceden ayarlanabilir.

İş istasyonu değiştirme ve Windows'un hedeflenmesi

Windows'u hedeflediyseniz veya tam iş istasyonu sanallaştırması yapmak istiyorsanız (projeye özgü ayarlara ek olarak istemci araçları ve konak işletim sistemi ayarları), VM'ler genellikle en iyi işlevselliği sağlar. Bu ortamlar, Windows istemci geliştirmesinden Windows hizmetine veya .NET tam çerçeve web uygulamalarını yönetmeye ve bakımını yapmaya kadar her şey için yararlı olabilir.

Yaklaşım	Örnekler
Bulutta barındırılan VM'leri kullanma	Microsoft Dev Box , masaüstü yönetim yazılımıyla yerleşik tümleştirmeye sahip tam bir Windows iş istasyonu sanallaştırma seçeneğidir.
Yerel VM'leri kullanma	Hashicorp Vagrant iyi bir seçenektir ve hem bu hem de Dev Box için VM görüntüleri oluşturmak için HashiCorp Packer'ı kullanabilirsiniz.

Çalışma alanı sanallaştırma ve Linux'ı hedefleme

Linux'ı hedeflediyseniz çalışma alanı sanallaştırma seçeneğini göz önünde bulundurun. Bu seçenekler geliştirici masaüstünüzü değiştirmeye daha az, projeye veya uygulamaya özgü çalışma alanlarına daha fazla odaklanır.

Yaklaşım	Örnekler
Bulutta barındırılan kapsayıcıları kullanma	GitHub Codespaces , VS Code, JetBrains'in IntelliJ ve terminal tabanlı araçlarıyla tümleştirmeyi destekleyen Dev Kapsayıcıları için bulut tabanlı bir ortamdır. Bu veya benzer bir hizmet gereksinimlerinizi karşılamıyorsa, uzak Linux VM'lerinde Geliştirme Kapsayıcıları ile VS Code'un SSH veya uzak tünel desteğini kullanabilirsiniz. Yalnızca istemciyle değil, web tabanlı vscode.dev de çalışan tünel tabanlı seçenek.
Yerel kapsayıcıları kullanma	Bunun yerine yerel Geliştirme Kapsayıcıları seçeneğini tercih ederseniz veya bulutta barındırılan bir seçeneğe ek olarak, Geliştirme Kapsayıcıları VS Code'da, IntelliJ'de ve diğer araç ve hizmetlerde sağlam desteğe sahiptir.
Bulutta barındırılan VM'leri kullanma	Kapsayıcıları çok sınırlayıcı bulursanız VS Code veya IntelliJ gibi JetBrains araçları gibi araçlardaki SSH desteği, kendi yönettiğiniz Linux VM'lerine doğrudan bağlanmanızı sağlar. VS Code'un tünel tabanlı seçeneği de burada çalışır.
Linux için Windows Alt Sistemi kullanma	Geliştiricileriniz yalnızca Windows kullanıyorsa Linux için Windows Alt Sistemi (WSL), geliştiricilerin Linux'u yerel olarak hedeflemesi için harika bir yoldur. Ekibiniz için bir WSL dağıtımını dışarı aktarabilir ve her şeyin ayarlandığı şekilde paylaşabilirsiniz. Bulut seçeneği için Microsoft Dev Box gibi bulut iş istasyonu hizmetleri, Linux geliştirmeyi hedeflemek için WSL'nin avantajlarından da yararlanabilir.

Doğru yapılandırmayı kullanmaya devam edin içeren doğru başlangıç uygulaması şablonları oluşturma

Kod deseni olarak her şeyin en iyi yanı, geliştiricileri en başından itibaren oluşturduğunuz yollarda tutabilmesidir. Kuruluşunuz için bu zor bir durumsa, uygulama şablonları hızla tutarlılığı sağlamak, standartlaştırmayı desteklemek ve kuruluşunuzun en iyi yöntemlerini koordine etmek için yapı taşları yeniden kullanmanın kritik bir yolu haline gelebilir.

Başlamak için GitHub şablon deposu kadar basit bir şey kullanabilirsiniz, ancak kuruluşunuz monorepo düzenine uyarsa bu daha az etkili olabilir. Ayrıca, doğrudan bir uygulama kaynak ağacıyla ilgili olmayan bir şey ayarlamanıza yardımcı olacak şablonlar da oluşturabilirsiniz. Bunun yerine cookiecutter, Yeoman veya Azure Developer CLI (azd) gibi bir şablon oluşturma altyapısı kullanabilirsiniz. Bu altyapı, şablon oluşturma ve basitleştirilmiş CI/CD kurulumuna ek olarak kullanışlı bir geliştirici komutları kümesi de sağlar. Azure Geliştirici CLI'sı tüm senaryolarda ortam kurulumunu yönlendirmek için kullanılabildiğinden, gelişmiş güvenlik, tümleşik IaC, ortam izleme, sorun ayrımı ve basitleştirilmiş CD kurulumu sağlamak için Azure Dağıtım Ortamları ile tümleştirilir.

Bir şablon kümeniz olduğunda geliştirme müşteri adayları, uygulamalarının içeriğini iskelelemek için bu komut satırı araçlarını veya diğer tümleşik kullanıcı deneyimlerini kullanabilir. Ancak, geliştiricilerin şablonlarınızdan depo veya başka içerik oluşturma izni olmayabilir, çünkü bu aynı zamanda el ile tetiklenen, parametreli iş akışlarını / işlem hatlarını kullanmak için başka bir fırsattır. Girişler ayarlayabilir ve CI/CD sisteminizin bir depodan altyapıya kadar her şeyi kendi adına oluşturmasını sağlayabilirsiniz.

Doğru kalmak ve sağa doğru devam etme

Ancak, ölçeklendirmeye yardımcı olmak için bu uygulama şablonları mümkün olduğunda merkezi yapı taşları (örneğin, IaC şablonları, hatta CI/CD iş akışları/ işlem hatları) başvurmalıdır. Aslında, bu merkezi yapı taşları kendi başlangıç şablonları biçimi olarak ele almak, tanımladığınız bazı sorunları çözmek için etkili bir strateji olabilir.

Bu tek tek şablonların her biri yalnızca yeni uygulamalara değil, güncelleştirilmiş veya geliştirilmiş yönergelerin dağıtılması için doğru seçim kampanyasının bir parçası olarak güncelleştirmeyi planladığınız mevcut şablonlara da uygulanabilir. Daha da iyisi, bu merkezileştirme hem yeni hem de mevcut uygulamaların doğru kalmasını sağlayarak zaman içinde en iyi uygulamalarınızı geliştirmenize veya genişletmenize yardımcı olur.

Şablon içeriği

Şablon oluştururken aşağıdaki alanları göz önünde bulundurmanızı öneririz.

Alan	Ayrıntılar
Uygulama desenlerini, SDK'ları ve araç kullanımını yönlendirmek için yeterli örnek kaynak kodu	Geliştiricileri önerilen dillere, uygulama modellerine ve hizmetlerine, API'lere, SDK'lara ve mimari desenlere yönlendirmek için kod ve yapılandırmayı ekleyin. Seçtiğiniz araçları kullanarak dağıtılmış izleme, günlüğe kaydetme ve gözlemlenebilirlik için kod eklemeyi unutmayın.
Derleme ve dağıtım betikleri	Geliştiricilere derlemeyi ve yerel /korumalı alan dağıtımlarını tetiklemenin ortak bir yolunu sağlayın. Kullanmak istediğiniz araçlar için IDE/düzenleyici hata ayıklama yapılandırmasını ekleyin. Bu, bakım baş ağrılarını önlemenin ve CI/CD'nin eşitlenmemiş olmasını önlemenin önemli bir yoludur. Şablon oluşturma altyapınız Azure Geliştirici CLI'sı gibi görünüyorsa kullanabileceğiniz komutlar zaten olabilir.
CI/CD yapılandırması	Önerilerinize göre uygulama derlemek ve dağıtmak için iş akışları/işlem hatları sağlayın. Güncel kalmalarına yardımcı olmak için merkezi, yeniden kullanılabilir veya şablonlu iş akışlarından/işlem hatlarından yararlanın. Aslında, bu yeniden kullanılabilir iş akışları / işlem hatları kendi şablonlarına başlayabilir. Bu iş akışlarını el ile tetikleme seçeneğini göz önünde bulundurun.
Kod varlıkları olarak altyapı	Herhangi bir altyapı kurulumunun en iyi yöntemleri izlediğinden emin olmak için merkezi olarak yönetilen modüllere veya katalog öğelerine başvurular da dahil olmak üzere önerilen IaC yapılandırmalarını sağlayın. Bu başvurular, zaman geçtikçe ekiplerin doğru şekilde kalmasına da yardımcı olabilir. İş akışları / işlem hatları ile birlikte, hemen her şeyi sağlamak için IaC veya EaC de ekleyebilirsiniz.
Kod varlıkları olarak güvenlik ve ilke	DevSecOps hareketi, güvenlik yapılandırmasını koda taşıdı. Bu, şablonlar için harika bir özelliktir. Kod yapıtları olarak bazı ilkeler de uygulama düzeyinde uygulanabilir. CODEOWNERS gibi dosyalardan GitHub Advanced Security'de dependabot.yaml gibi tarama yapılandırmasına kadar her şeyi dahil edin. Ortam test çalıştırmalarıyla birlikte Bulut için Defender gibi bir şey kullanarak taramalar için zamanlanmış iş akışları /işlem hattı çalıştırmaları sağlayın. Bu, tedarik zinciri güvenliği için önemlidir ve uygulama paketlerine ve koda ek olarak kapsayıcı görüntülerini de dikkate almayı unutmayın. Bu adımlar geliştirme ekiplerinin doğru kalmasına yardımcı olur.
Gözlemlenebilirlik, izleme ve günlüğe kaydetme	Self servis özelliğini etkinleştirmenin bir parçası, dağıtıldıktan sonra uygulamalara kolay görünürlük sağlamaktır. Çalışma zamanı altyapısının ötesinde, gözlemlenebilirlik ve izleme için kurulum eklemeyi unutmayın. Çoğu durumda, ayarlanması gereken bir IaC yönü (örneğin aracı dağıtımı, izleme) varken, diğerlerinde ise başka bir tür kod olarak yapılandırma yapıtı (örneğin, Azure Uygulaması lication Insights için panoları izleme) olabilir. Son olarak, seçtiğiniz araçları kullanarak dağıtılmış izleme, günlüğe kaydetme ve gözlemlenebilirlik için kod örneği kodu eklediğinizden emin olun.
Kodlama ortamı kurulumu	Lintleri, biçimlendiricileri, düzenleyicileri ve IDE'leri kodlamak için yapılandırma dosyalarını ekleyin. devcontainer.json, devbox.yaml , geliştirici odaklı Dockerfiles, Docker Compose dosyaları veya Vagrantfiles gibi çalışma alanı veya iş istasyonu sanallaştırma dosyalarıyla birlikte kurulum betikleri ekleyin.
Test yapılandırması	Kullanıcı arabirimi için Microsoft Playwright Testing veya Azure Load Testing gibi tercih ettiğiniz hizmetleri kullanarak hem birim hem de daha ayrıntılı test için yapılandırma dosyaları sağlayın.
İşbirliği aracı kurulumu	Sorun yönetimi ve kaynak denetimi yönetim sisteminiz kod olarak görev/sorun /ÇEKME isteği şablonlarını destekliyorsa, bunları da ekleyin. Daha fazla kurulumun gerekli olduğu durumlarda, isteğe bağlı olarak kullanılabilir bir CLI veya API kullanarak sistemlerinizi güncelleştiren bir iş akışı/işlem hattı sağlayabilirsiniz. Bu, Microsoft Teams veya Slack gibi diğer işbirliği araçlarını da ayarlamanıza olanak sağlayabilir.