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

Platform mühendisliği yolculuğunuzda ilk olarak ele almak istediğiniz sorunları anladıktan sonra, geliştirici self servisini geliştirmek listenin en üstüne çıkabilir. Otomatik self servis deneyimlerini etkinleştirmeye başlamanın en kolay yollarından biri, mevcut mühendislik sistemlerinizi yeniden kullanmaktır. Bu sistemler hem size hem de şirket içi müşterilerinize aşina olmakla kalmaz, aynı zamanda ilk kullanıcı deneyimi güzel olmasa bile çok geniş bir otomasyon senaryolarına olanak sağlayabilir.

Bu makalede, daha geniş bir self servis senaryolarıyla başa çıkmak için mühendislik sistemlerinizi uygulamaya yönelik bazı ipuçları ve doğru başlangıç yapmanıza ve doğru şekilde çalışmaya başlamanıza yardımcı olacak şablonlara en iyi yöntemleri nasıl kapsülleyebileceğiniz anlatılacaktır.

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

Mühendislik sistemleri, iç geliştirici platformunuzun kritik bir yönüdür. Ancak, DevOps ve DevSecOps'un ana kiracılarından en az bazılarını hedefleyen herhangi bir sisteminiz yoksa, tanımladığınız sorunlar büyük olasılıkla buradan başlamanızı söyler. İç geliştirici platformları, dahil olan herkesin bilişsel yükünü azaltmak için bu platformlardan biriker.

Özetlemek gerekirse DevOps, geliştirme ve işlemleri birleştirerek uygulama planlama, geliştirme, teslim ve operasyonlardaki kişileri, süreçleri ve teknolojileri birleştirir. Geliştirme, BT operasyonları, kalite mühendisliği ve güvenlik gibi geçmişe dönük silolu roller genelinde işbirliğini geliştirmeyi amaçlamaktadır. 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 oluşturur.

Microsoft'un DevOps kaynak merkezi , ihtiyacınız olan işlem ve sistem türleri hakkında tavsiye almak için harika bir yerdir, bu nedenle bu bölümde bunları ayrıntılı olarak ele almayız. Bunlar, siz ilerledikçe temel bileşenler haline gelir. Ayrıca , planlarınızda kapsayıcı tedarik zinciri güvenliği gibi son DevSecOps konularını da hesaba katmayı unutmayın.

Sürekli geri bildirim hakkında daha fazla bilgi için bkz. dikkate alınacak ölçümler. Ayrıca uygulama platformunuzu geliştirme bölümündeki gözlemlenebilirlik, izleme ve sürekli geri bildirim alanlarında kullanıma yönelik araçlar hakkında daha fazla bilgi edinebilirsiniz.

Bu makalenin geri kalanında platform mühendisliği hareketine daha doğrudan atfedilen iyileştirmelere odaklanacağız: kaldırımlı 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 fazla araç kümeniz varsa, ilk platform mühendisliği çalışmalarınızın bir parçası olarak bunları birleştirmekten geçmek mi yoksa başlangıçtan itibaren farklı araçların takımyıldızını desteklemek mi istediğinize karar vermeniz gerekir. Çoğu durumda, 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 kaymaya başladığınızda, bu döşeli yollar içindeki mühendislik sistemlerini geliştirme ekiplerine merkezi olarak hizmet olarak yönetilen araçlardan oluşan bir araç olarak düşünebilirsiniz. Kuruluşunuzdaki tek tek ekipler veya bölümler bundan sonra sapmaya devam edebilir, ancak uyumluluk gereksinimlerine bağlı kalırken araçlarını ayrı ayrı yönetmesi, koruması ve ödemesi beklenir. Bu, zaman içinde kaldırımlı bir yola olası bir şekilde dahil olmak için sapan her şeyi değerlendirebileceğinizden ekosisteme yeni araçlar beslemek için bir yol sağlar. Bir platform mühendislik liderinin belirttiği gibi:

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

Platform mühendisliğinin temel hedeflerinden biri, iç müşterilerinize değer sağladığınız ürün anlayışına geçmek olduğu düşünüldüğünde, bu ekip takımı yaklaşımı genellikle yukarıdan aşağıya bir görevden daha iyi çalışır. Siz yollarınızı oluşturup iyileştirdikçe, bazı esneklikler bırakmak ekiplerin kuruluştaki diğer uygulamaları 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öşenmiş. Benzersiz gereksinimlerin olmadığı durumlarda, geliştirme ekiplerinin üstlendiği ek iş ekipleri doğal olarak zaman içinde desteklenen bir yola geçmek istemelerine neden olur.

Birleştirme stratejisini tercih ediyorsanız, mevcut uygulamaları geçirmenin beklediğinizden daha fazla iş olabileceğini unutmayın, 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, mevcut olan her şey doğal olarak kaydedilmez. Ardından, yeni yolunuzun değerini kuruluşa 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 herkesi istediğiniz duruma getirmek için doğru seçim kampanyası yürütebilirsiniz. Kampanya sırasında platform mühendisliği ekipleri ekiplerin geçişlerine yardımcı olmaya odaklanabilirken, geliştirme ekipleri de yolların daha iyi hale nasıl getirebileceğine ilişkin geri bildirimde bulunabilir.

Ne olursa olsun, döşeli yollarınızın kullanımını mandating önlemeye çalışın. Bunları kullanıma sunmanın en etkili yolu, ekiplerin zorla benimseme yerine onlardan ne elde ettiğinizi vurgulamadır. İç geliştirici platformunuz tam olarak aynı ekipleri mutlu etmeye odaklandığından, tek tek liderler üzerinde bütçe ve değer baskısı geri kalanıyla ilgilenme eğilimindedir. Doğru kampanyaları alın, ardından iki yönlü konuşmalar için en iyi yol olan, ödenmemiş bir yoldaki kişilerin geçiş yapmalarına olanak tanıyın.

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ı, çekirdek 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ştirmenin (CI) ve sürekli teslimin (CD) çözüme yardımcı olabileceği sorunlara işaret eder. 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, CD işlem hattınızın bir parçası olarak gerekli uygulama altyapısını oluşturmak veya güncelleştirmek için kod olarak altyapıyı (IaC) kullanmayı da göz önünde bulundurmanız gerekir.

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

Her yaklaşım hakkında daha fazla bilgi edinmek için bkz. GitHub Actions ve Gitflow ile AKS uygulamaları için CI/CD.

Seçtiğiniz özellik genellikle mevcut IaC beceri kümenize ve hedef uygulama platformunuzun ayrıntılarına göre belirlenir. GitOps yaklaşımı daha yenidir ve uygulamaları için temel olarak Kubernetes kullanan kuruluşlar arasında popülerdir. Çekme tabanlı model, kullanılabilir seçenek sayısı göz önünde bulundurulduğunda size en fazla esnekliği sunar. Ç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üllerinibir kayıt defterinde, Bicep modüllerinde, Radius tariflerinde veya Azure Container Registry (ACR), DockerHub gibi bulutta yerel bir 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ı için ek destek sağlayabilir ve Çapraz Düzlem gibi diğer araçlar birden çok bulut genelinde 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ıkları için güncelleştirme yapabilecek kişiler ü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 bir kaza sonucu 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ı yapılarından da yararlanırlar.

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 artılarını 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ı (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 "ortam türüne" göre yönetilen kimlikler ve abonelikler 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 veya Azure Developer CLI kullanarak temel alınan aboneliğe veya kimliklere 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 sistemi gizli dizileri ayırarak ve geliştiricilerin kendi kendilerine erişemeyeceği veya değiştiremeyeceği konumlardan 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ışında senaryolarda self servis etkinleştirme

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

Bunun nerelere yardımcı olabileceğini anlamak için şu anda el ile veya hizmet masası tabanlı işlemlerinizin nerede olduğunu 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 yatkın 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 kaynaklanıyor?
• Onaylayan gerekiyorsa, 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 süreçlere geçmeden önce başlangıç olarak daha düşük risk içeren süreçler var mı?

Sık, yüksek çaba veya hataya eğilimli işlemleri öncelikle otomatikleştirmeye yönelik olası hedefler olarak belirleyin. Şimdi bunu yapmanın birkaç basit yolunu ele alacağız.

Her şeyi kod deseni olarak kullanma

Git'in yaygınlığının yanı sıra iyi özelliklerinden biri de 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 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, neredeyse her şeyi güvenli bir git deposundaki bir dosyaya dönüştürebilmenizdir. Daha sonra depoya bağlı farklı araçlar veya aracılar içeriği okuyabilir. Şablon oluşturma yoluyla her şeyi kod yardımcıları olarak tekrarlanabilirlik olarak ele almak ve geliştirici self servis hizmetini basitleştirir. Bunun nasıl çalışabileceğine birkaç örnek inceleyelim.

Herhangi bir altyapıya IaC desenleri uygulama

IaC, uygulama teslimini otomatikleştirmeye yardımcı olmak için 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 en sevdiğiniz işbirliği araçlarını ayarlama.

Bunun çalışma şekli, sağlanması ve yapılandırılması gerekenleri temsil eden bir dizi dosyayı (bu durumda Bicep, Terraform'dan Helm grafiklerine ve diğer Kubernetes yerel biçimlerine) barındıran ayrı, güvenli bir merkezi deponuz olmasıdır. Bir operasyon ekibi veya diğer yönetici kümesi depoya sahip olur 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 ve IaC ile 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 dışında genişletmenize olanak tanır:

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

PR'leri hazırlayan kişilerin bu gizli dizilere doğrudan erişimi olmayacağından, geliştiricilerin kendileri için doğrudan izinleri olmayan eylemleri güvenli bir şekilde başlatması için bir yol sağlar. Bu, geliştiricilere 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 bir gerçek kaynağıdır, ancak oluşturduğunuz URI'leri ve durum bilgilerini size söylemez. Ancak, kod olarak her şeyi takip etmek, sağlanan altyapı envanterini sentezlemek için size dokunabileceğiniz bir bilgi kaynağı sağlar. Sağlama sağlayıcınız da 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 özellikleri 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, ilkeyi kod desenleri olarak uygulama

Altyapı sağlama 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 denetim 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,Açık İlke Aracısı, 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 geliştirme.

Kendi senaryolarınız için her şeyi kod olarak kullanma

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ünü 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 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, denetim ve geri alma avantajlarını elde eder ve ilgili 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ını/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 özelliğini etkinleştirebilir.

Bu düzenin olgun ve kapsamlı bir çeşitlemesi örneği için , Yetkilendirmeleri nasıl yönettiklerine ilişkin GitHub'ın blog gönderisine göz atın. GitHub, karmaşık Yetkilendirme uygulamalarını denemeniz veya benimsemeniz için açık kaynaklı olarak da 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 hiç temsil edilmeyebilir ve ekip üyelerini ekleme veya çıkarma sürecini karmaşık hale getiren ö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 şunları varsayıyoruz:

1. İ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.
2. Karmaşıklığı azaltmak ve merkezi denetimi sürdürmek amacıyla üyeliği role göre yönetmek için sistemler arasında kimlik sağlayıcısı gruplarını (örneğin, Entra grupları) kullanacaksınız.

Yüksek düzeyde, bu desen şu şekilde çalışır:

1. Merkezi, kilitli git deposunda her soyut ekibi, ilgili kullanıcı üyeliğini ve kullanıcı rollerini temsil eden bir dizi (genellikle YAML) dosyası bulunur. Ekip değişikliklerinin sahipleri /onaylayanları da aynı yerde (örneğin , CODEOWNERS aracılığıyla) depolanabilir. Bu dosyalardaki bir kullanıcıya başvuru, kimlik sağlayıcısıdır, ancak bu depo bu ekipler (kullanıcılar için değil) için gerçek kaynağı görevi görür.
2. Kod örneği olarak diğer her şeyde olduğu gibi, bu dosyalardaki 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.
3. Müşteri adayları ve tek tek kullanıcılar kişi eklemek/kaldırmak için ÇEKME'ler oluşturabilir ve müşteri adayları ve diğer roller şablondan yeni bir ekip dosyası içeren PR'leri kullanarak yeni ekipler oluşturabilir.
4. 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:

5. Rol başına bir kimlik sağlayıcısı grubu oluşturmak veya dosyadaki bireylerle (artık, daha azı değil) güncelleştirmek için uygun kimlik sağlayıcısı sistem API'sini kullanır.
6. Her bir aşağı akış sistemi için API'leri kullanarak bu sistem gruplandırma kavramını her rol için sağlayıcı gruplarını (örneğin: GitHub ve Azure DevOps) tanımlamaya bağlar. Bu, bir rolü temsil etmek için ekibinizle aşağı akış sistemi arasında bire çok ilişkisine neden olabilir.
7. İ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.
8. 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şunuzda Zaten Entra Yetkilendirme Yönetimi gibi bir şey kullanılıyorsa, grup üyeliğini yönetmeyi bu düzenden atlayabileceğinizi unutmayın.

gereksinimleriniz ve ilkeleriniz belirli özellikleri değiştirebilir, ancak genel desen herhangi bir sayıda varyasyona uyarlanabilir. Herhangi bir aşağı akış sistemiyle tümleştirmek için gereken tüm gizli diziler CI/CD sisteminde (örneğin, GitHub Actions,AzurePipelines'da) 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 neden olmayabilir. Veya self servis deneyimini yönlendirmek için kullanmak istediğiniz bir kullanıcı arabiriminiz olabilir.

Neyse ki, GitHub Actions ve Azure Pipelines dahil olmak üzere çoğu CI sistemi, kendi URI'leri veya CLI'leri aracılığıyla el ile tetikleyebileceğiniz girişlerle bir iş akışı ayarlama özelliğine sahiptir. 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 tam otomatikleştirilmesi gereken etkinliklerde (veya işlerde) otomasyonu etkinleştirmek için her şeyi kod deseni olarak genişletebilir.

Aslında, CI sisteminiz bir API aracılığıyla kendi kullanıcı deneyimlerinizden bu iş akışlarını / işlem hatlarını tetiklemenizi kabul etmenize izin verebilir. GitHub Actions için bu işi yapmanın anahtarı, bir iş akışı çalıştırmasını tetikleyen bir iş akışı dağıtma olayını tetikleyen Eylemler REST API'leridir. Azure DevOps tetikleyicileri benzerdir ve çalıştırmalar için Azure DevOps İşlem Hattı 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 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ışı/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. Ancak, bu iş akışları / işlem hatları tarafından gerçekleştirilen tüm eylemlerin aşağı akış sistemlerine sistem kimliği (örneğin, Microsoft Entra ID hizmet sorumlusu veya yönetilen kimlik) gibi görünmesi göz önünde bulundurulmasıdır.

CI/CD sisteminizde istekleri kimin başlattığını göreceksiniz, 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 gereksinimlerinize uygun 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 ilişkin resmi olmayan bir kayıt sağlar. Bu 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 açık 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 sistemlerinizin yardımcı olabileceğini belirleyebileceğiniz bir diğer yaygın sorun da geliştirici kodlama ortamı önyüklemesi 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 (matrisli kuruluşlar gibi) aktardığınızda, yüklenicileri artırmanız gerektiğinde veya işe alma aşamasında olan bir ekipte olduğunuzda sorunlu bir alandır.
• Geliştiriciler ve 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, inceleme tamamlandıktan sonra test etmek ve geri almak için bir yapılandırma değişikliği gerektirebilecekleri için kod incelemeleri 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, QA, iş, sponsorlar) artırmaya zaman harcamaları gerekir.

Döşeli yollarınızın bir parçası

Bu sorunları çözmeye yardımcı olmak için, iyi tanımlanmış yollarınızın bir parçası olarak belirli araçları ve yardımcı programları ayarlamayı 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'ı hedefleme

Windows'u hedefliyorsanız 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'ı hedefliyorsanız çalışma alanı sanallaştırma seçeneğini göz önünde bulundurun. Bu seçenekler daha çok geliştirici masaüstünüzü değiştirmeye, daha çok projeye veya uygulamaya özgü çalışma alanlarına odaklanır.

Yaklaşım	Örnekler
Bulutta barındırılan kapsayıcıları kullanma	GitHub Codespaces , VS Code, JetBrains'in IntelliJ'leri ve terminal tabanlı araçlarla tümleştirmeyi destekleyen Dev Kapsayıcıları için bulut tabanlı bir ortamdır. Bu veya benzer bir hizmet ihtiyaçlarınızı 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 ile de çalışan tünel tabanlı seçenek.
Yerel kapsayıcıları kullanma	Bunun yerine yerel Bir Geliştirme Kapsayıcıları seçeneğini tercih ederseniz veya bulutta barındırılan bir seçeneğe ek olarak , Dev KapsayıcılarıVS Code'da sağlam destek, IntelliJ'de destek ve diğer araç ve hizmetlere 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çlarda SSH desteği, kendi yönettiğiniz Linux VM'lerine doğrudan bağlanmanızı sağlar. VS Code'da tünel tabanlı seçenek 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 şey ayarlanmış şekilde paylaşabilirsiniz. Bulut seçeneği için Microsoft Dev Box gibi bulut iş istasyonu hizmetleri de Linux geliştirmeyi hedeflemek için WSL'nin avantajlarından yararlanabilir.

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

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

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

Bir şablon kümesine sahip olduktan sonra geliştirme liderleri bu komut satırı araçlarını veya diğer tümleşik kullanıcı deneyimlerini kullanarak uygulamalarının içeriğinin iskelesini oluşturabilir. 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 ayarlayarak CI/CD sisteminizin depodan altyapıya kadar her şeyi kendi adına oluşturmasını sağlayabilirsiniz.

Sağa doğru devam etme 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ıç sağ şablonları biçimi olarak ele almak, tanımladığınız bazı sorunları çözmek için etkili bir strateji olduğunu fark edebilirsiniz.

Bu tek tek şablonların her biri yalnızca yeni uygulamalara değil, güncelleştirilmiş veya geliştirilmiş yönergeleri dağıtmak için doğru alma kampanyasının bir parçası olarak güncelleştirmek istediğiniz 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	Şey
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ı dahil edin. 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. Bunları 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 Developer CLI gibi görünüyorsa, kullanabileceğiniz komutlar zaten olabilir.
CI/CD yapılandırması	Önerilerinize göre uygulama oluşturmak 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 dikkate almayı unutmayın.
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 ayrıca güvenlik yapılandırmasını koda taşımıştır ve bu da şablonlar için harikadır. Kod yapıtları olarak bazı ilkeler de uygulama düzeyinde uygulanabilir. CODEOWNERS gibi dosyalardan GitHub Advanced Securitydependabot.yaml gibi tarama yapılandırmasına kadar her şeyi ekleyin. Ortam testi ç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 özellikle tedarik zinciri güvenliği için önemlidir ve uygulama paketlerine ve koda ek olarak kapsayıcı görüntülerini de dikkate alın. Bu adımlar geliştirme ekiplerinin doğru şekilde 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 ayarlanacak bir IaC yönü (örneğin, aracı dağıtımı, izleme) varken, diğerlerinde bu başka bir kod olarak yapılandırma yapıtı türü olabilir (örneğin, Azure Uygulaması Insights için panoları izleme). 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. kurulum betiklerini 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 ekleyin.
Test yapılandırması	Kullanıcı arabirimi veya Azure Yük Testi için Microsoft Playwright 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 görev / sorun / ÇEKME isteği şablonlarını kod olarak 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.

Uygulama platformunuzu geliştirme