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

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, mühendislik sistemlerinizi çeşitli self servis senaryolarını ele almak için uygulamaya yönelik ipuçları ve doğru başlayıp doğru bir şekilde devam etmenize yardımcı olacak şablonlarda en iyi uygulamaları nasıl kapsülleyebileceğiniz 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ı, herkesin bilişsel yükünü azaltmak için DevOps ve DevSecOps'un ana ilkelerinden yola çıkılarak kurulur.

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.

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 araçlar dizisi içinde belirlenmiş bir dizi yol tanımlamak en etkili yöntemdir ve daha fazla esneklik sağlar.

Ürün zihniyetine doğru geçiş yapmaya başladığınızda, bu yerleşik yollar içindeki mühendislik sistemlerini, geliştirme ekiplerine bir hizmet olarak merkezi şekilde yönetilen araçlar olarak düşünün. Kuruluşunuzdaki tek tek ekipler veya bölümler gerektiğinde farklı yöntemler izleyebilir, ancak uyumluluk gereksinimlerine bağlı kalarak, araçlarını ayrı ayrı yönetmeleri, bakımını yapmaları ve ödeme yapmaları 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. Bir platform mühendisliği yöneticisinin 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. Yollarınızı oluşturup iyileştirdikçe, biraz esneklik bırakmak ekiplerin diğerlerini etkilemeden belirli bir uygulama için gerçekten benzersiz gereksinimlere katılım sağlamasına ve bunları karşılamasını sağlar. 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, ekiplerin doğal olarak üstlendiği ek iş geliştirmesi, 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, ilk asfalt yolunuzu sağlarken mevcut olan her şeyin doğası gereği asfaltlanmamış olduğuna işaret eder. Yeni asfaltlanmış yolunuzun kuruluşa sağladığı değer ortaya çıktığında, asfaltlanmamış yoldaki geliştirme ekipleri de taşınmayı düşünebilir. Bu noktada, geliştirme ekipleri bunu bir vergi değil, bir avantaj olarak değerlendirdiğinden, iki yönlü iletişimle herkesin istediğiniz duruma gelmesi için bir iyileştirme kampanyası yürütebilirsiniz. Kampanya sırasında platform mühendisliği takımları, takımların geçişine yardımcı olmaya odaklanabilirken, geliştirme takımları da yolları nasıl daha iyi hale getirebilecekleri konusunda geri bildirimde bulunabilir.

Ne olursa olsun, asfalt yollarınızın kullanımını zorunlu kılmaktan kaçının. Döşenmiş yolların etkili bir şekilde uygulanmasının en iyi yolu, ekiplerin bu yollardan ne elde ettiklerini vurgulamak, zorla benimsetmek yerine bunu öne çıkarmaktır. İç geliştirici platformunuz tamamen aynı ekipleri mutlu etmeye odaklandığından, kalan baskılar bütçe ve zaman-değer açısından tek tek liderler tarafından yönetilir. Doğru kampanyalara odaklanın ve ardından, dolambaçlı bir yolda olanların en iyi şekilde geçiş yapabilmesi için iki yönlü konuşmalar sağlayacak bir yol oluşturun.

Hazır çözümleriniz için kendi kendine hizmeti geliştirmek amacıyla geliştirici otomasyon araçlarını kullanın.

İlk asfalt yolunuzu oluşturmanın bir parçası, temel geliştirici otomasyon ürünlerinizi oluşturmanız 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 aşağıdaki ç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ı olabilir.

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 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. Crossplane 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ığı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, operasyon ve platform mühendislerinin gerekli değişiklikleri yaptığı kod güncellemeleri sırasında, yanlışlıkla yapılan bir değişikliğin neden olduğu hatalı sonuç riskinin daha düşük olması sağlanı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 inkübasyon projesi, Kubernetes'i doğrudan kullanmaya kıyasla daha katı varsayımlar ortaya koymakla birlikte geliştirici deneyimini kolaylaştırmaktadır. Farklı modellerin avantajları ve dezavantajları hakkında bilgi edinmek için bkz. Bulut hizmeti türlerini açıklama. 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 doğrudan erişemeyeceği bir şekilde gerekli sağlama kimliklerini veya gizli anahtarları kalıcı hale getirmek, yönetişim için temel yapı taşlarını oluşturur. Ö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 ortam türüne göre yönetilen kimlikler ve abonelikler ekleyebilir ve bunları sağlama için kullanmasına izin verilen geliştiricileri ve diğer kullanıcıları 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 eforlu 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 güzel özelliklerinden biri, güvenli ve denetlenebilir bir bilgi kaynağı olmasıdır. İşleme geçmişi ve erişim denetimlerinin ötesinde, pull request 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 sağlamak için bir yapı sunar. 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. Ardından depoya bağlı farklı araçlar veya aracılar içeriği okuyabilir. Her şeyi kod olarak ele almak, şablonlama yoluyla tekrarlanabilirliğe ve geliştirici kendi kendine servis işlemlerini basitleştirmeye yardımcı olur. Şimdi 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ı değil, sağlamak ve yapılandırmak isteyebileceğiniz tüm altyapı, araçlar veya hizmetlere de uzanır. Örneğin, Flux yüklü paylaşılan Kubernetes kümeleri, 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, sağlanması ve yapılandırılması gereken öğeleri temsil eden bir dizi dosyanın barındırıldığı ayrı, güvenli bir merkezi deponuz olmasıdır (bu örnekte Bicep veya Terraform'dan Helm grafiklerine ve diğer Kubernetes yerel biçimlerine kadar her şey). Bir operasyon ekibi veya diğer yönetici kümesi deponun sahibidir ve geliştiriciler (veya sistemler) çekme istekleri (PR) 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 gösteren aşağıdaki ç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 hazırlayan kişilerin bu gizli bilgilere doğrudan erişimi olmadığından, geliştiricilerin doğrudan izinleri olmayan eylemleri güvenli bir şekilde başlatmalarına olanak tanır. 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 bir gerçek kaynağıdı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, ilkenin kod kavramı olarak yükselmesine yol açtı. Burada, bir kaynak denetimi deposundaki yapılandırma dosyaları, güvenlik taramasını yönlendirme veya altyapı ilkeleri 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ı benimsemiş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.

PR, farklı süreçler için, özellikle başlangıç aşamasında, iyi bir temel kendi-kendine hizmet kullanıcı deneyimi oluşturur. İş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 Takımlar

Her şeyi kod olarak kendi senaryolarınıza uygulamanın bir örneği, ekipleri kod olarak uygulama desenidir. 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 manuel ekleme ve çıkarma hizmet masası işlemlerini ortadan kaldırır. Hizmet masası işlemlerinin el ile yürütülmesi, erişimin fazla sağlanabilmesi mümkün olduğundan potansiyel bir güvenlik riskidir. tr-TR: Kod deseni olarak ekipleri kullanırken, Git ve PR'lerin birleşimi denetlenebilir bir veri kaynağından kendi kendine hizmet sağlamayı mümkün kılabilir.

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ı da açık kaynaklı hale getirmekte. 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 üyeliği role göre yönetmek için sistemler arasında kimlik sağlayıcısı gruplarını (örneğin, Entra grupları) kullanırsınız.

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

• Merkezi, kilitli bir 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 dosyalarda bir kullanıcıdan bahsedildiğinde, bu kimlik sağlayıcısını ifade eder, ancak bu depo bu ekipler için (kullanıcılar için değil) gerçek kaynak olarak işlev görür.
• Bu dosyalardaki tüm güncellemeler, birleştirme istekleri aracılığıyla yapılır. Bu, konuşmaları ve ilgili katılımcıları denetlenebilirlik için bir Git commit'ine bağlar.
• Takım ve geliştirici liderleri ile bireysel kullanıcılar, kişi eklemek veya çıkarmak için PR oluşturabilir ve takım liderleri ile diğer roller, şablondan alınan yeni bir ekip dosyasıyla PR kullanarak yeni ekipler oluşturabilir.
• Bir PR ana dala birleştirildiğinde, depoya bağlı bir CI/CD sistemi kimlik sağlayıcı sistemini ve tüm alt sistemleri uygun şekilde güncelleştirir.

Özellikle, CI/CD sistemi:

• Rol başına, dosyadaki bireylerle tam olarak eşleşen bir kimlik sağlayıcı grubu oluşturmak veya güncellemek için uygun kimlik sağlayıcı sistem API'sini kullanır (ne bir kişi fazla ne bir kişi eksik).
• Her aşağı akış sistemi için API'leri kullanarak sistem gruplandırma kavramını her rol için tanımlayıcı sağlayıcı gruplarına (örneğin GitHub ve Azure DevOps) bağlar. Bu, ekibinizle alt sistem arasında bir rolü temsil etmek için bire çok ilişkisine yol açabilir.
• (İ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.
• Kısıtlanmış bir veri deposunu, sonuçları (alt sistem ekip kimliklerini ilişkilendirme dahil) güncellemek için bir API kullanır; böylece bu sonuçlar iç sistemlerinizde kullanılabilir. 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. Aşağı akış sistemleriyle tümleştirmek için gereken tüm gizli diziler CI/CD sisteminde (örneğin GitHub Actions veya Azure Pipelines' da) veya Azure Key Vault gibi bir yerde 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ı arabiriminiz olabilir.

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ştiricilerin ve ilgili operasyon rollerinin büyük olasılıkla bu kullanıcı deneyimlerini zaten bildiği göz önünde bulundurulduğunda, manuel tetikleyiciler, doğal bir dosya biçimi olmayan veya tamamen otomatikleştirilmesi gereken ve PR süreci gerektirmeyen etkinliklerin (veya işlerin) otomasyonunu sağlamak için her şeyin kod olarak kullanıldığı deseni 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şlemi yapmanın anahtarı, bir iş akışı çalışımını başlatmak için iş akışı dağıtım olayını tetikleyen Actions REST API'sinin kullanılmasıdır. 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, entegre ettiğiniz araçların kendi izleme mekanizmalarına başvurabilirsiniz. Ö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ışı motorları, genellikle bu kalıpların kullanışlılığını daha da artırmak için işletim araçlarıyla tümleştirmeye yönelik 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 pull request'e 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 liderleri için kod incelemeleri, bunlar tamamlandıktan sonra test etmek ve geri almak için bir yapılandırma değişikliği gerektirebileceğinden geliştirmeyi yavaşlatabilir.
• Ekip üyeleri ve operatörler, test, ilerlemeyi görmek, iş rollerini eğitmek ve ekibin yaptığı işi tanıtmaya yardımcı olmak için geliştirme dışında ilgili rolleri (operatörler, Kalite Güvencesi, iş, sponsorlar) geliştirmeye de zaman harcamalıdırlar.

Döşenmiş patikalarınızın bir kısmı

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 geliştirme makinesi kurulumu, size yardımcı olabilir ve aynı 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 sanal makineleri 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'da tünel tabanlı seçenek de burada çalışır.
Linux için Windows Alt Sistemini 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 ayarları koruyan yapılandırmaya sahip doğru başlangıç uygulama şablonları oluşturma

Kod deseni olarak her şeyin harika yanı, geliştiricileri en baştan 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ı veya 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ı ve 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.

Area	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 komut dosyaları	Geliştiricilere bir derlemeyi başlatmanın ve yerel/kısıtlı alan dağıtımı yapmanın 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 senkronize olmamasını önlemenin önemli bir yoludur. Şablon oluşturma altyapınız Azure Developer CLI gibi görüş sahibiyse, kullanabileceğiniz komutlar mevcut 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. Bunları güncel tutmaya yardımcı olmak için merkezi, yeniden kullanılabilir veya şablonlu iş akışlarından yararlanın. Aslında, bu yeniden kullanılabilir iş akışları / işlem hatları kendi başlarına şablon olarak kullanılabilir. 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 referanslar, zaman geçtikçe ekiplerin doğru yolda 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'dedependabot.yaml gibi tarama yapılandırmasına kadar her şeyi dahil edin. Tarama süreçlerinde zamanlanmış iş akışları ve işlem hattı çalıştırmalarını, Bulut için Defender gibi araçlar kullanarak ortam test çalıştırmalarıyla birlikte 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 yönde ilerlemesine 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 Application 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 Uygulama Testi 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 kontrol yönetim sisteminiz görev/sorun/pull 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.

İlgili içerik

• Microsoft'un DevOps kaynak merkezi
• Kapsayıcılar Güvenli Tedarik Zinciri Çerçevesi
• Azure Pipelines ile CI/CD temel mimarisi
• Uygulama platformunuzu geliştirme