Geliştirici self servis temeli tasarlama

Mühendislik sistemleriniz için hedefinizi iyi anladıktan sonra daha gelişmiş geliştirici self servis deneyimleri oluşturmaya başlayabilirsiniz. Bu bölümde, bunları oluşturmak için esnek bir temel oluşturan ürünleri oluşturmaya veya değerlendirmeye yönelik kavramsal bir mimari açıklanmaktadır. Bu kavramlara, desenlere ve bileşenlere, bir geliştirici self servis temeli olarak topluca atıfta bulunuruz.

Kuruluşunuzda bugün burada açıklanan her şeye ihtiyacınız olmayabilir ancak özel bir şey oluşturursanız veya ilgili ürünleri değerlendirirseniz bu kavramları göz önünde bulundurmanız gerekir. Sizin dünyanızda, bu model evde yetiştirilen, kullanıma hazır ve açık kaynak ürünlerin bir birleşiminden oluşabilir. Backstage.io gibi ürünler veya açık kaynak portal araç setleri, bu bölümde açıklanan modelin bazı öğeleri için farklı terimler kullanabilir, ancak model yine de yönlendirmenize yardımcı olabilir.

Goals ve dikkat edilmesi gerekenler

Bu alandaki çabalarınızın temel amacı, denetimli, yönetilen görev yürütme ve sağlama ile merkezi görünürlük aracılığıyla korumalarla self servis sağlamak olmalıdır. Odaklanmak için genellikle en değerli olan alanlar yorucu olan veya geliştiricinin karmaşıklık veya izinler nedeniyle kendi kendine gerçekleştiremeyenlerdir. Bu son parça, el ile hizmet masası işlemi aracılığıyla geliştiricileri zorlamadan en az ayrıcalık ilkesini izlemenizi sağlamak için önemlidir.

DevOps paketinizi bu gereksinimleri karşılayacak şekilde genişletmeyi tercih edebilirsiniz ancak büyük olasılıkla zaman içinde birden çok uygulama platformunu desteklemeniz gerekir ve bunları destekleyen belirli araç ve işlemlerin de değişmesi gerekir. Temel sorun, standartlarınızın hareketli bir hedef olmasıdır. Bir platform mühendislik uygulayıcısı tarafından belirtildiği gibi:

Zorluklar standartlaştırmayı içerir... ve 'abandonware' ile ilgileniyor... Standartlaştırma genellikle otomatikleştirilmiş işlemlerin olası kesintisi ve gerekli değişiklikleri belirlemenin zaman alan görevi nedeniyle elde edilmeyebilir. - Martin, DevOps Mühendisi, Büyük Lojistik Şirketi

Bu alıntının da vurgulandığı gibi, yeni veya güncelleştirilmiş bir standarda hızla geçmek genellikle uygun değildir ve mevcut işlemleri bırakmak risk oluşturur. Kuruluşunuz zaten senaryoya göre birden çok DevOps paketi veya farklı araç ve geliştirici hizmetleri bileşimleri kullanıyor olabilir. Merkezi bir ekip ve standart bir çözümle bile self servis ihtiyaçlarınız arttıkça değişkenlik kaçınılmazdır. Bu nedenle, belirlenen ekiplerin yeni teknolojileri, dağıtım stratejilerini vb. deneyebileceği ve ardından kasıtlı benimseme ve artımlı bir dağıtım gerçekleştirebileceği denetimli denemeyi etkinleştirmek isteyeceksiniz.

Self servis deneyimleri genellikle iki birincil kategoriye ayrılır:

• Otomasyon
• Veri toplama

Veri toplama iyi kullanıcı deneyimleri oluştururken, bir platform mühendisliği uygulayıcısı şunu ifade eder:

Otomasyon çok önemlidir ve herkes tarafından sevilecektir. [Veri] toplama ikincildir. – Peter, platform mühendisliği Lideri, Çok Uluslu Teknoloji şirketi

Bu nedenle, büyük olasılıkla grafik oluşturduğunuz platform mühendisliği yolculuğunda otomasyonla çözülebilecek bazı sorunlar tespit edildi. Otomasyon, bilişsel yükü ve geliştirici yükünü azaltmanın ötesinde, uygulamaların işlerini yapmak için en iyi araçlara ve hizmetlere operasyon, güvenlik ve diğer rollere bağlanmasını sağlamaya da yardımcı olabilir.

Ancak, otomasyonunuzu yönlendirmek için birden fazla sistemle çalışıyorsanız, otomatik isteklerin ve ilişkili sonuçların izlenmesine yardımcı olmak için bazı veri toplama düzeyleri yararlı olur. Genellikle diğer gereksinimleri karşılamak veya ayrıntıları detaylandırmak için dış sistemlere bağlanarak işe başlayabilirsiniz. Veri toplama ve görünürlük denetimi, idare ve israfı azaltma (örneğin, kullanılmayan ortamlar) için de önemlidir.

Altyapı sağlama gibi işlemleri otomatikleştirme işlemi sistem tümleştirmeleri kullanılarak yapılabilir, ancak geliştiriciye otomatik görünen bir el ile iş akışı işlemini de tetikleyebilir ve kolaylaştırabilirsiniz. Bu, platformunuzun ilk aşamalarında, ekosisteminize getirdiğiniz yeni ürünler için veya sistem kullanarak otomatikleştirmediğiniz veya otomatikleştiremediğiniz alanlarda (örneğin, yazılım lisans ataması) yararlıdır. Doğru tasarımla, Power Automate gibi bir şey tarafından kolaylaştırılan ve zaman içinde tam otomatik bir akışa geçiş yaptığınız el ile gerçekleştirilen bir işlemle başlayabilirsiniz. Bu nedenle, başlangıçtan itibaren bir otomasyon tasarımı.

Bir ürün anlayışı ve en ince uygulanabilir platform (TVP) ( platformunuz için bir MVP ) fikri göz önüne alındığında, mühendislik sistemleriniz veya bir iç portal gibi mevcut yatırımları yeniden kullanarak basit bir başlangıç yapmanız, ardından CLI'ler, temel web sayfaları, hatta Power Pages, Power BI veya Microsoft Fabric panoları oluşturmanız ve ihtiyaç duyulduğunda genişlemeniz gerekir. Bunu göz önünde bulundurarak, UX'in kullandığı tutarlı bir API'ye sahip olmak, gereksinimleriniz ve tercihleriniz değiştikçe zaman içinde birden çok arabirimi desteklemenize yardımcı olabilir.

Kavramlara genel bakış

Aşağıdaki çizimi göz önünde bulundurun:

Çizimde gösterildiği gibi, aşağıdaki bileşenler geliştirici self servis temeli kavramının temelini oluşturur:

Bileşen	Açıklama
Geliştirici platformu API'si	Bu, kullanıcı deneyimleri için tek iletişim noktanızdır. Bu, sistemin diğer sistemlerle olan sözleşmesini etkili bir şekilde ifade eder.
Geliştirici platformu grafı	Farklı türlerde varlıkları ve şablonları bulmanızı, ilişkilendirmenizi ve kullanmanızı sağlayan yönetilen ve güvenli bir veri grafiği. Varlık, birden çok kaynaktan veri toplamayı etkinleştirirken şablonlar otomasyonu etkinleştiren kullanıcı girişlerini yönlendiren bir nesnedir.
Geliştirici platformu düzenleyicisi	Bir sistemde veya el ile gerçekleştirilen bir işlem aracılığıyla eylem gerçekleştirmek için şablon tabanlı istekleri yönlendiren ve izleyen bir özellik. Bu istekler, herhangi bir sayıda farklı iş akışı sistemi veya diğer hizmetlerle tümleştirebilen bir dizi geliştirici platformu sağlayıcısına yönlendirilir.
Geliştirici platformu sağlayıcıları	Varlıklar üzerinde CRUD işlemlerini desteklemek ve/veya şablon tabanlı eylem isteklerinin yerine getirilmesini desteklemek için aşağı akış sistemleriyle tümleştirmek için gereken mantığı kapsülleyen bir bileşen kümesi. Her sağlayıcı kendi özel şablon türünü destekleyebilir ve benzersiz veya ortak varlık türlerini yayar.
Kullanıcı profili ve ekip meta verileri	Geliştirici platformu API'sini gruplandırmak ve erişmek için kavramsal ekiliğe bağlı bir grup kişi hakkındaki bilgileri kalıcı hale getirmek için bir özellik. Kullanıcı bir kimlik sağlayıcısı hesabıyla (örneğin, Microsoft Entra ID oturum açma) yakından ilişkilidir, ancak hem o hem de ekip ilgili herhangi bir sayıda aşağı akış sistemi gösterimine bağlanabilir. Bu bilgi deposunun bir uygulaması, geliştirici platformu grafını yeniden kullanmaktır. Geliştirici self servis temeli, hem kullanıcı hem de ekip için ortak bir varlık türü oluşturabilir ve bu bilgileri grafikte kalıcı hale getirmenizi sağlayabilir. Ancak, bu mağazayı burada netlik sağlamak için ayrı tutacağız.

Bu temel bileşenler, zaman içinde farklı yapı taşlarını kullanmanıza ve değiştirmenize olanak tanır. Sonraki bölümlerde bunların her birini daha ayrıntılı olarak inceleyeceğiz.

Başlamak için bunların tümünü derlemem gerekiyor mu?

No. İlk olarak, bu, böyle bir temel yapıldıktan sonra neler yapabilmesi gerektiğini düşünmenize yardımcı olan kavramsal bir modeldir. İkinci olarak, geliştirici platformu API'sinin temel arabiriminiz haline gelmesi durumunda uygulama ayrıntıları burada daha az önemlidir. İlk uygulamanız, diğer ürünlerde açıklanan veya karıştırılan farklı katmanlar için kodunuzdaki arabirimleri ve sınıfları kullanarak başlayabilir. Müşteri geliştirmeniz yalnızca daha düşük öncelikli olduğunu söylediğinden, bu özellikleri atlayabilirsiniz. Sahip olduğunuzla başlayın ve büyüyün.

Bunu göz önünde bulundurarak, her parçanın daha derinine inelim.

Geliştirici platformu API'si

Sisteminizin sözleşmesi olarak hareket etmek için bir geliştirici platformu API'sini tanımlamanız gerekir. API, veri erişimini veya sürücü sağlamayı ve diğer eylemleri etkinleştirmek için farklı kullanıcı arabirimleri tarafından kullanılır.

Bu API ayrıca diğer sistemlerdeki ham temel API'lere erişimi daha belirli, denetimli veri ve işlemlerle sınırlayarak önemli bir kimlik doğrulama ve güvenlik katmanı görevi de üstlenmelidir. API, bir kullanıcı profilinin kendi gösterimine, bir kullanıcının platformdaki üst düzey rolüne (ekip üyesi, yönetici vb.) ve birincil kimlik sağlayıcısı sistem tanımlayıcılarına erişim sağlar. Daha fazla bilgi için bkz . Kullanıcılar ve ekipler.

Geliştirici platformu sağlayıcıları

Bir iç geliştirici platformunun genişliği göz önünde bulundurulduğunda, API'ye işlevsellik kazandırmak için genişletilebilir bir sağlayıcı modelini izleyen sistemler oluşturmanızı veya bu sistemleri aramanızı öneririz. Otomasyon ve veri toplama gibi temel işlevlerin iyi tanımlanmış arabirimlere sahip eklenebilir bileşenlerle etkileşim kurarak sağlanması fikridir. Bu gevşek bağlantı, ihtiyacınız olanları artımlı olarak bağlamanıza yardımcı olur ve temelin geri kalanından bağımsız olarak işlevselliği test edebilirsiniz.

Ayrıca, platformunuzda ölçeklenebilir bir iç kaynak zihniyetini etkinleştirmenin de önemli bir yoludur. Genellikle platform mühendisliğiyle ilgili iç kaynak oluşturma çalışmaları, devam eden bakımla ilgili zorluklardan dolayı zorluk çekememektedir. Diğer ekipler işlevlere katkıda bulunmaya istekli olabilir ancak platformunuzun çekirdeğindeki bir şeyi korumaya ve test etmeye daha az istekli olabilir. Buna karşılık, tüm merkezi ekiplerin katkıda bulunan kodu korumak ve hatta çekme isteklerini gözden geçirmek için sınırlı kapasitesi vardır. Geliştirici platformu sağlayıcısı kavramı, bağımsız olarak yazılmış kodun geliştirici self servis temelinizdeki temel işlevlere "takılmasına" izin vererek bu gerilimi ortadan kaldırmayı sağlar. Hangi sağlayıcıları kullandığınızı dikkatle yönetmeniz, herhangi bir sağlayıcı kodunu gözden geçirmeniz ve belirli bir sağlayıcının geliştirici platformunuzda erişebileceği yüzey alanını sınırlamanız gerekir ancak eklenebilir bir yaklaşım, kuruluşun daha geniş bir bölümünde çabayı ölçeklendirerek daha fazlasını başarmanıza yardımcı olabilir.

Önemli geliştirici platformu sağlayıcısı kavramları

Varlık

Varlık kavramı, iç geliştirici platformunuzda bir geliştiricinin veya başka bir sistemin izlemesi, güncelleştirmesi, sunması veya üzerinde işlem yapması gereken bir kavramdır. Varlıklar, bir araya getirildiğinde iç geliştirici platformunuzun parçaları hakkında kritik bilgiler sağlayan bir graf oluşturan birbirleriyle ilişkiler kurabilir. Geliştirici platformu sağlayıcıları daha sonra aşağıdakiler de dahil olmak üzere temel özellikleri etkinleştirmek için varlıkların çıkışını alabilir:

• Dışarıdan sağlanan kaynakları/ ortamları veya bulma ve kullanım için kullanılabilir API'leri bulma
• Bağımlılık analizi, etki analizi, bulma vb. için ilişkileri kullanıma sunar.
• Keşif ve işbirliği için bakımcı / sahiplik bilgileri
• Kullanıcı deneyimlerinde kullanmak için daha fazla veri ekleme

Bu işlevi iyi tanımlanmış bir geliştirici platformu sağlayıcısı arabiriminde kapsüllemek tümleştirmeyi ve testi basitleştirir, bağımsız dağıtıma olanak tanır ve birincil iç geliştirici platformu ekibinin dışındaki geliştiricilerin sağlayıcılara katkıda bulunup yönetmesine olanak tanır. Bu, her araç, hizmet veya platformun merkezi olarak yönetilmediği, ancak daha geniş bir kuruluşun hala özellikleri paylaşmak istediği büyük veya bölünmüş kuruluşlarda önemlidir. Bu nedenle, başlangıçta bu yola gitmeseniz bile, uzun vadede düşünmeniz gereken bir şey.

Ortak özellikler

Her varlığın, Foundation'ın bunları yönetmesine izin vermek için bir ortak özellikler kümesi olmalıdır. Dikkate alınması gereken bazı özellikler şunlardır:

• Benzersiz tanımlayıcı
• Adı
• Kaynak sağlayıcı
• İsteğe bağlı ilişkilendirmeler:
  • Sahip olan kullanıcı
  • Sahip olan ekip
  • Diğer varlıklar

Kullanıcı ve ekip özellikleri üç nedenden dolayı önemlidir: rol tabanlı erişim denetimi (RBAC), bulma ve veri toplama (ekip düzeyi özetleri gibi). RBAC'de en baştan oluşturmak, güvenlik açısından kritik öneme sahiptir ve zaman içinde iç geliştirici platformunuzu büyütür. Geliştirme bir takım sporu olduğundan, bir varlık hakkında kiminle konuşulacağını keşfetmek, yeniden kullanım, destek ve iç kaynak kullanımı için hızla kritik hale gelecektir.

Ortak ve sağlayıcıya özgü varlıklar

Ayrıca, birden çok sağlayıcının çıktısını alabildiği bir dizi ortak üst düzey, normalleştirilmiş varlık oluşturabilmeniz gerekir. Örneğin:

• Ortam
• Kaynak
• Apı 'leri
• Depoları
• Bileşen
• Araçları

Bunlar genellikle C4 model bağlamında veya en üst düzey bileşen diyagramlarında yerleştirdiğiniz gibi yüksek düzeyde olmalıdır. Örneğin, bir ortam için iç altyapı topografisinin ayrıntılarını eklemeniz gerekmez: Aynı UX'teki birden çok sağlayıcının farklı kavramsal ortamlarını listelemek ve ilişkilendirmek için yeterli bilgiye ihtiyacınız vardır. Varlık, her şeyi tüketmeye çalışmak yerine sistem dışında daha düşük ayrıntı düzeylerine işaret edebilir. Bunlar, zaman içinde veri toplamayı etkinleştirmenin merkezi olan bulma için başlangıç noktaları sağlar.

Diğerleri belirli bir kullanım örneğine veya sağlayıcıya özgü olacaktır, bu nedenle zamanla büyüyen bir varlık türü kümesini nasıl barındırabileceğinizi düşünmeniz gerekir.

Şablon

Bu bağlamda şablon kavramı, varlıkların eyleme geçme amacına sahip olması fikrinden farklıdır. Örnek senaryolar arasında altyapı sağlama, depo oluşturma ve uzun süre çalışan diğer işlemler yer alır. Bu şablonlar genişletilebilir geliştirici platformu sağlayıcıları aracılığıyla da kullanılabilir olmalıdır ve varlık ilişkilendirmeleri de dahil olmak üzere varlıklarla aynı ortak özellikleri desteklemelidir.

Ancak, eylemi gerçekleştirmek için gerekli olan sistem veya kullanıcı tarafından belirtilen gerekli girişleri de tanımlayabilirler. Bunlar, kaynağı adlandırmak gibi her şeyden isteğe bağlı eklemelere kadar değişebilir.

Şablon örnekleri şunlardır:

• Kod olarak altyapı (IaC) şablonları
• Uygulama şablonları (Sağa Başlat) veya şablon depoları
• İşlem hattı / iş akışı şablonları oluşturma
• Dağıtım işlem hattı / iş akışı şablonları
• Parametreli betikler
• Parametreli Power Automate akışları (örnek: HTTP isteğinin tetiklediği bulut akışı)
• Email şablonları

Varlıklar gibi şablonlar da sağlayıcıya özgü özellikler içerebilir.

Her şablonun sağlayıcıya özgü farklı bir gösterimi olabilir. Bunlar Terraform veya ARM şablonlarından Helm Grafiklerine, parametreli GitHub Actions iş akışlarına veya Azure Pipelines'a, basit betiklere veya özel biçimlere kadar değişebilir.

Temel alınan asıl şablon ayrıntılarının merkezi olarak depolanması gerekmez. Bunlar farklı depolarda, kayıt defterlerinde veya kataloglarda bulunabilir. Örneğin, IaC şablonlarınız geliştiricilerin yalnızca Azure Dağıtım Ortamları gibi bir şey aracılığıyla dolaylı olarak erişebileceği kısıtlı bir katalog deposunda bulunabilirken, uygulama şablonlarınız için GitHub şablon depolarını kullanabilirsiniz. Diğer IaC şablonları Helm grafikleri gibi bir OCI Yapıt Kayıt Defteri'nde depolanabilir. Diğer durumlarda şablon, parametreli HTTP uç noktasına başvuru olabilir. Geliştirici platformu sağlayıcısı, başvurulabilmesi için her şablon türü ve kullanıcı deneyimlerinde kullanılmak üzere kullanıma sunulan tüm seçenekler hakkında yeterli bilgi sağlamalıdır. Ancak, şablonların kendileri kullanım örnekleriniz için en doğal konumda barındırılabilir.

Belirli bir alandaki platform mühendisleri veya uzmanlar bu şablonu yazar ve yeniden kullanmak üzere geliştirme ekipleriyle paylaşır. Bir sistem aracılığıyla bu şablonların kullanımını merkezileştirmek, geliştirici self servisini etkinleştirir ve kuruluş standartları veya ilkeleriyle uyumluluğu zorlamaya yardımcı olan korumalar oluşturur. Geliştirici platformu düzenleyicisini biraz daha ele aldığımızda bu konuda daha fazla bilgi edinebilirsiniz.

Geliştirici platformu grafı

Geliştirici platformu grafını, birden çok sağlayıcının varlıklarını ve şablonlarını aranabilir bir grafikle ilişkilendirmenizi sağlayan bir şey olarak düşünebilirsiniz. Ancak varlıklar için gerçek verilerin doğrudan grafa özgü bir veritabanında kalıcı olması gerekmez. Bunun yerine sağlayıcılarla etkileşimler, her şeyin birbirine uygun olması için gerekli meta verilerle birlikte önbelleğe alınabiliyordu.

Grafik, birden çok sağlayıcının katkıda bulunabileceği ortak varlıklarla kullanıldığında güçlüdür. Örneğin, API'lerin listesi Azure API Center gibi bir üründen gelebilir, ancak sürekli dağıtım sistemlerinizden dağıtımlarda ve ortamlarda otomatik olarak beslemek de isteyebilirsiniz. Zaman içinde farklı dağıtım sistemleri arasında geçiş yapabilir, hatta birden fazla dağıtım sistemini destekleyebilirsiniz. Her dağıtım sisteminin bir geliştirici platformu sağlayıcısı olduğu sürece ilişkilendirmeyi yine de yapabilmeniz gerekir.

Bu grafikten oluşan kullanıcı deneyimlerinizin her biri, bulma, arama, idare ve daha fazlası için ortak bir API'den yararlanabilir. Bir geliştirici platformu düzenleyicisi daha sonra aynı grafikten yararlanabilir, böylece geliştirici platformu sağlayıcısı tarafından gerçekleştirilen tüm eylemler aynı API'nin kullanılabilir varlıklarına otomatik olarak katkıda bulunabilir.

Geliştirici platformu düzenleyicisi

Geliştirici platformu düzenleyicisi, geliştiricilerin veya sistemlerin şablon kullanarak eylem gerçekleştirme istekleri oluşturmasına olanak tanır. Bu eylemleri gerçekleştirmez, bunun yerine bir görev altyapısı, iş akışı altyapısı veya başka bir düzenleyici ile eşgüdüm sağlar. Bu, self servis temelinizin bir parçası olduğundan emin olmak isteyeceğiniz kritik parçalardan biridir. Geliştiricilerin bir şablonla istek oluşturmasına veya doğrudan izin olmadan bir eylem yürütmesine olanak tanır. Ayrıca, CI veya CD kavramından farklı olarak, bu eylemlerin uygulama kaynak koduyla ilgili olması gerekmez.

Yazılım mühendisliği sistemlerini uygulama bölümünde açıklandığı gibi GitHub Actions, Azure Pipelines veya başka bir iş akışı altyapısını düzenleyici olarak kullanabilirsiniz. Bu başlangıç için makul bir yerdir, ancak farklı şablon türlerinin farklı temel altyapılar kullanmasına izin vermek için biraz soyutlama yapmak isteyebilirsiniz. Bu birkaç nedenden dolayı yararlı olabilir:

• İlk olarak, büyük olasılıkla flash kesmeye gerek kalmadan zaman içinde farklı iş akışı ve görev yürütme altyapıları seçebilmek isteyeceksiniz. Birden fazla altyapıya izin vererek, zaman içinde geçiş yapabilir veya yeni altyapıyı eskilerini etkilemeden yeni eylemlere geçirebilirsiniz.
• Düzenlemeye yardımcı olmak istediğiniz bazı işlemler, daha sonra bunları tam olarak otomatikleştirmeyi planlasanız bile başlangıçta el ile gerçekleştirilen adımları gerektirebilir.
• Diğer eylemler, ödemesi yapılan hesaplar veya lisans yöneticisi gibi geliştirme ekibinin dışındaki rolleri hedef alabilir. Power Automate gibi düşük kodlu altyapılar genellikle bu roller için iyi çalışır.
• Diğer eylemler, GitHub Actions veya Azure Pipelines'ın ölçeklendirme için gerekli veya uygun maliyetli olmadığı basit HTTP istekleriyle işlenebilir.

Neyse ki, otomasyon adımlarını tetikleme ve izleme konularını kapsayacak şekilde geliştirici platformu sağlayıcısı fikrini genişletmek bu gerekli soyutlamayı sağlayabilir. Aşağıdaki çizimi göz önünde bulundurun:

Genel kavram şu şekildedir:

1. Şablonlar isteğe bağlı olarak kullanıcının girebileceği bir dizi giriş belirtebilir. Geliştirici belirli bir eylemi tetiklediğinde, bir şablon (bu şekilde açıklanmasa bile) seçer ve herhangi bir giriş girer.
2. Şablonla ilgili girişlere başvuru, geliştirici platformu API'sinde bir istek haline gelir.
3. İstek gönderildikten sonra, düzenleyici içindeki bir istek yönlendirme ve işleme bileşeni isteğin yaşam döngüsünü izlemeye başlar. İstek yönlendirme ve işleme bileşen yolları şablonu, istekte şablonun kaynaklandığı geliştirici platformu sağlayıcısına yönlendirilir.
4. Geliştirici platformu sağlayıcısı daha sonra uygulaması için uygun adımları gerçekleştirebilir.
5. [İsteğe bağlı] Geliştirici platformu sağlayıcısı, eylemi gerçekleştirirken istek durumunu güncelleştirir.
6. İstek yerine getirildikten sonra geliştirici platformu sağlayıcısı, geliştirici platformu grafiğine eklemek/güncelleştirmek için bir varlık kümesi döndürebilir. Bunlar sağlayıcıya özgü veya ortak varlıklar olabilir.

İsteğe bağlı olarak, daha gelişmiş etkileşimleri desteklemek için bu geliştirici platformu sağlayıcılarının giriş olarak daha fazla varlık almak ve hatta başka bir ilgili eylem istemek için doğrudan geliştirici platformu API'sini çağırmasına izin vekleyebilirsiniz.

Değerlendirdiğiniz belirli bir çözüm veya ürün farklılık gösterse de, bu size aranacak nitelikler konusunda fikir verecektir.

Bunu göz önünde bulundurarak, genel bir görev veya iş akışı altyapısı kullanan bir geliştirici platformu sağlayıcısına sahip olmak istersiniz. Daha açık belirtmek gerekirse, Yazılım mühendisliği sistemlerini uygulama kapsamında bir araya getirdiğinizde bir köprü oluşturmak isteyeceksiniz. Büyük olasılıkla yatırım yapacağınız bir genel iş akışı veya görev yürütme altyapısı CI/CD sisteminizdir.

GitHub Actions veya Azure Pipelines'ın kullanıldığı bir örnek

Şimdi geliştirici platformu sağlayıcısı olarak bir GitHub Actions veya Azure Pipelines'ın nasıl çalışacağını kısaca inceleyelim.

GitHub Actions için, bu işi yapmanın anahtarı, geliştirici platformu sağlayıcısının belirtilen GitHub örneğine bağlanabilmesi ve eylemler REST API'sini kullanarak bir iş akışı çalıştırmasını tetikleyen bir iş akışı dağıtma olayını tetikleyebileceğidir. Her iş akışı, iş akışı YAML dosyasına bir workflow_dispatch yapılandırması ekleyerek bir dizi girişi destekleyebilir. 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.

Bu iş akışlarının/işlem hatlarının uygulama kaynak kodu depolarında olması gerekmez. Kavram şu şekilde bir şey yapmak için bu olgudan yararlanmak olacaktır:

1. Platform mühendisleri veya DevOps ekip üyeleri, geliştiricilerin kendilerine erişimi olmayan bir veya daha fazla merkezi depoda iş akışlarını/işlem hatlarını koruyabilir, ancak geliştirici platformu sağlayıcısı kullanılacak şekilde ayarlanmıştır. Bu depo, iş akışlarının/işlem hatlarının kullandığı betikleri ve IaC kod parçacıklarını içerebilir.
2. Bu iş akışlarının/işlem hatlarının uygun aşağı akış sistemiyle etkileşim kurmasına izin vermek için, operasyonlar veya platform mühendislik ekibinizin diğer üyeleri gerekli gizli dizileri merkezi depoya ekleyebilir. Bunun nasıl yapılacağını öğrenmek için GitHub Actions ve Azure DevOps belgelerine bakın veya Azure Key Vault gibi bir şey kullanarak gizli dizileri merkezileştirmeyi tercih edebilirsiniz.
3. Bu iş akışları/işlem hatları daha sonra elde edilen varlıkları derleme/dağıtım yapıtı olarak yayımladıkları bir modeli izleyebilir (GitHub belgeleri, Azure DevOps belgeleri).
4. Bir çalıştırma sırasında geliştirici platformu sağlayıcısı iş akışının/işlem hattının durumunu watch ve tamamlanana kadar düzenleyicide yaşam döngüsü durumunu güncelleştirebilir. Örneğin, güncelleştirmeleri izlemek için GitHub Actions ile web kancalarını ve Azure Pipelines ile hizmet kancalarını kullanabilirsiniz.
5. İşlem tamamlandıktan sonra sağlayıcı, yayımlanan yapıtı gerektiği gibi geliştirici platformu grafiğine eklemek için kullanabilir.

Son olarak, bu geliştirici platformu sağlayıcısını uygun depoya ve iş akışına / işlem hattına başvuran bir şablon kümesini ve belirli bir görevin girişlerini geliştirici platformu grafiğine çıkaracak şekilde ayarlayabilirsiniz.

CI/CD sisteminizi kullanmanın en iyi tarafı, bunların genellikle rastgele CLI'leri çalıştırmayı destekleyecek şekilde ayarlanmış olmasıdır, bu nedenle yaptığınız her şey için birinci sınıf, benzersiz bir tümleştirmeye ihtiyacınız yoktur. Bunları zaman içinde gerektiği gibi ekleyebilirsiniz.

Bu örnekte açıklananların çoğu, diğer sağlayıcı türlerinin nasıl çalışabileceğini uygular. Bu bağlamda GitHub Actions veya Azure Pipelines kullanımının, bunları gerçek CI/CD işlem hatlarınız için de kullanmanızı gerektirmediğini unutmayın.

Diğer örnekler

Burada şablonları işleyebilen diğer geliştirici platformu sağlayıcısı türlerinin bazı örnekleri verilmiştir.

Örnek	Açıklama
Kaynak denetimi işlemleri	Bazı durumlarda depo oluşturmanız veya güncelleştirmeniz, çekme isteği göndermeniz veya başka bir kaynak denetimiyle ilgili işlem gerçekleştirmeniz gerekebilir. Genel zaman uyumsuz iş akışı altyapıları bu tür işlemleri yönetebildiğinden, temel Git işlemlerini tek bir işlem olmadan gerçekleştirebilmek yararlı olabilir.
Altyapı hazırlayıcıları	GitHub Actions ve Azure Pipelines, altyapı sağlamayı yönetmek için iyi bir şekilde çalışsa da, daha fazla doğrudan tümleştirme de seçebilirsiniz. Ayrılmış bir sağlayıcı kurulumu kolaylaştırabilir ve ek yükten kaçınabilir. Azure Dağıtım Ortamları veya Terraform Cloud gibi hizmetler, IaC şablon tabanlı sağlamayı ve güvenli bir şekilde ve güvenli bir şekilde etkinleştirmeye daha doğrudan odaklanır. Diğer örnekler, paylaşılan kümelerdeki uygulamalar için Kubernetes ad alanları oluşturma veya belirli bir sağlayıcı türü olarak Flux veya Argo CD kullanarak GitOps iş akışlarıyla git kullanma gibi işlemler olabilir. Kendi CLI'lerine sahip deneysel Radius OSS inkübasyon projesi gibi uygulama odaklı modellerin de zaman içinde kendi geliştirici platformu sağlayıcıları olabilir. Önemli olan, uyum sağlayabilmeniz için genişletilebilirliği aramak ve planlamaktır.
Uygulama iskelesi / tohumlama	Uygulama şablonları, platform mühendisliğinin zaman içinde liderlik yaptığı önemli bir noktadır. Yalnızca bir uygulama kaynak ağacının iskelesini oluşturmak için değil, aynı zamanda içerik oluşturup kaynak kod deposuna göndermek ve sonuçta elde edilen varlıkları grafiğe eklemek için tasarlanmış özel bir geliştirici platformu sağlayıcısı sağlayarak şablon altyapınızı destekleyebilirsiniz. Yeoman, cookiecutter veya Azure Developer CLI gibi her ekosistemin kendi uygulama iskelesi tercihi vardır, bu nedenle buradaki sağlayıcı modeli aynı arabirimlerinizden birden fazla uygulamayı desteklemenizi sağlayabilir. Burada da önemli olan genişletilebilirliktir.
El ile işlemler	Geliştirici olmayan kişilerin Power Platform gibi bir şey kullanarak yanıt vermeleri için el ile onay için veya el ile iş akışı adımları için otomatik olarak çekme isteği oluşturma, aynı şablon tabanlı model geliştirici platformu sağlayıcısında kullanılabilir. Hatta zaman içinde daha otomatik adımlara geçebilirsiniz.

Tüm bu sağlayıcıların başlatılmasına gerek duymasanız da, geliştirici platformu sağlayıcısı gibi bir şey aracılığıyla genişletilebilirliğinizin otomasyon özelliklerinizin zaman içinde büyümesine nasıl yardımcı olabileceğini görebilirsiniz.

Kullanıcılar ve ekipler

Platform mühendisliği doğası gereği çok sistemli bir iştir, bu nedenle bir self servis temelinin bu sistemleri birlikte tümleştirmeyle ilgili daha zorlu sorunları nasıl ele alacağını planlamak önemlidir. Bu bölümde kimlik, kullanıcı ve ekiplerle ilgili yaygın sorunları ele almak için bir strateji ele alacağız.

İlk olarak şu iki öneriyi göz önünde bulundurun:

Öneri	Açıklama
En iyi güvenlik için geliştirici platformu API'sini doğrudan kimlik sağlayıcınızla tümleştirme	Geliştirici platformu API'sinin güvenliğini sağlamak için sağlam kimliği ve Entra Id'nin rol tabanlı erişim denetimi (RBAC) özellikleri göz önünde bulundurulduğunda Microsoft Entra ID gibi bir kimlik sağlayıcısıyla doğrudan tümleştirme yapmanızı öneririz. Bir kimlik sağlayıcısının yerel SDK'larını ve API'lerini (örneğin, MSAL Entra ID aracılığıyla) soyutlama yerine doğrudan kullanmanın birçok avantajı vardır. Koşullu erişim ilkelerinin sürekli olarak değerlendirilmesini sağlarken (yalnızca oturum açma sırasında değil) uçtan uca güvenlik sağlayabilir ve aynı RBAC modeline güvenebilirsiniz.
Aşağı akış sistemlerinde çoklu oturum açma ve kimlik sağlayıcısı grubu tümleştirmelerini kullanma	Çoklu oturum açma (SSO) tümleştirmeleriniz, geliştirici platformu API'niz için kullandığınız kimlik sağlayıcısını ve kiracıyı kullanmalıdır. Ayrıca KIMLIK sağlayıcısı gruplarına (AD grupları gibi) bağlanmak için SCIM gibi protokoller için destek avantajlarından yararlanmayı unutmayın. Bu kimlik sağlayıcısı gruplarını aşağı akış sistemi izinlerine bağlama her zaman otomatik değildir, ancak en azından daha sonra üyeliği el ile yönetmeden sağlayıcı gruplarını her aracın gruplandırma kavramlarıyla el ile ilişkilendirebilirsiniz. Örneğin, GitHub'ın Kurumsal Yönetilen Kullanıcı (EMU) desteğini birleştirerek kimlik sağlayıcısı gruplarını GitHub ekiplerine bağlama özelliğinden el ile yararlanabilirsiniz. Azure DevOps da benzer özelliklere sahiptir.

Bundan sonra bu önerilerden oluşturarak bu alanda daha zorlu sorunların giderilmesine yönelik bir model oluşturacağız.

Tek bir kimlik sağlayıcısı grubunun ötesinde bir ekip kavramı oluşturma

Platform mühendisliği yolculuğunuz devam ederken, kimlik sağlayıcısı gruplarının üyeliği yönetmek için harika olduğunu ancak rol tabanlı erişim denetimi (RBAC) ve veri toplama için bir ekip kavramı oluşturmak için birden çok grubun bir araya gelmesi gerektiğini fark edersiniz.

Platform mühendisliği bağlamında, ekibi birlikte çalışan farklı rollere sahip bir grup insan olarak tanımlarız. Veri toplama için çok rollü bir ekip fikri, raporlama panoları gibi yerlerdeki bilgileri bulma ve toplama konusunda kritik öneme sahiptir. Öte yandan grup, bir kullanıcı kümesi için genel bir kimlik sağlayıcısı kavramıdır ve tam tersi yerine belirli bir role birden çok kişi ekleme fikriyle tasarlanmıştır. Bu nedenle RBAC ile bir ekip, farklı roller aracılığıyla birden çok kimlik sağlayıcısı grubuyla ilişkilendirilebilir.

Ekip verilerinizin kaynağı birkaç farklı yerden gelebilir. Örneğin, ekipleri kod deseni (TaC) olarak kullanıyorsanız geliştirici platformu sağlayıcısı depodaki dosya değişiklikleri için watch ve bunları bir kullanıcı profilinde ve ekip meta veri deposunda önbelleğe alabilir. İsterseniz, bu çekirdek RBAC yapılarının zaten kullanılabilir olduğu bir Azure Dev Center Projesi gibi bir projeyle doğrudan tümleştirebilirsiniz.

Ekip veya kullanıcı düzeyinde aşağı akış sistemleriyle tümleştirmeye yönelik bir model oluşturma

Bazı geliştirici ve operasyon araçları/hizmetleri kimlik sağlayıcısı kavramlarını doğrudan yerel olarak tümleştirip kullansa da, birçoğu bunu kendi grup veya kullanıcı temsili (SSO ile bile) olarak soyutlar. Bu gerçeklik, araçlar arasında erişimi etkinleştirmenin ötesinde veri toplama konusunda da sorunlara yol açabilir. Özellikle, aşağı akış sistemindeki API'lerin kimlik sağlayıcısı tanımlayıcıları yerine kendi tanımlayıcılarını kullandığını fark edebilirsiniz (örnek: Entra Kimliği'ndeki Nesne Kimliği doğrudan kullanılmaz). Bu, farklı kimlikler arasında eşleme yapmadığınız sürece kullanıcı veya ekip düzeyinde verileri filtrelemeyi ve ilişkilendirmeyi zorlaştırır.

Ekip ve grup düzeyi farklılıklarını ele alma

TaC gibi desenler, her sistemin ekip veya grup tanımlayıcıları arasındaki ilişkileri depolamanıza ve bunlara erişmenize olanak tanıyarak bunlar arasında eşleme yapmanızı sağlayabilir. Özetlemek gerekirse, güvenli, denetlenebilir bir Git deposu bir ekibin kaynağı olur ve PR'ler güncelleştirme yapmak için denetimli bir kullanıcı arabirimi sağlar. CI/CD sistemleri daha sonra aşağı akış sistemlerini güncelleştirebilir ve bunu yapmak için kullandığı ekip için ilgili tanımlayıcı ilişkilerini sürdürebilir.

Örneğin, bu, AŞAĞıDAKI ilişkilerin API çağrılarında depolanmasını sağlar:

Ekiplerinizin deposundaki dosyalardan başka bir veri kaynağı kullanmayı tercih ederseniz, aynı şeyi gerçekleştirmek için geliştirici platformu düzenleyicisi kullanılarak aynı genel kavram uygulanabilir. Bu model kapsamında, ekip verilerinin kaynağı için geliştirici platformu sağlayıcısı, diğer tüm sağlayıcıların uygun şekilde aldığı ve üzerinde işlem yaptığı bir ekip güncelleştirme olayını tetikleyebilir.

Kullanıcı kimliği sorunlarını giderme

Veri erişimi ve toplamayla ilgili bir diğer zorluk da kullanıcı kimliği farklılıklarıdır. Ekip örneğinde olduğu gibi, bir kullanıcı hakkındaki verileri sorgulamak için sistemden sisteme tümleştirme kullanırsanız, kimlik sağlayıcılarının yerel kimliğinin (örneğin, Entra Kimliği için Nesne Kimliği) belirli bir API'yi desteklediğini varsayamazsınız. Burada da geliştirici platformu API'si aracılığıyla verilere erişen bir kullanıcı kimliğine yönelik eşlemenin depolanması yardımcı olabilir. Örneğin GitHub'ı göz önünde bulundurun:

Her sistem için, kullanıcı belirteci olmayan bir API aracılığıyla başka bir sistem için kullanıcı kimliği araması yapabilirseniz, belirli bir geliştirici platformu sağlayıcısı bu eşlemeyi anında oluşturabilir. Bazı durumlarda, bu işlemi toplu olarak gerçekleştirmeniz ve performansı korumak için sonuçları başvuru için önbelleğe almanız gerekebileceğinden bu durum karmaşık olabilir.

Birden çok kullanıcı belirteci kullanmaya geri dönme

Sağlayıcıların işe yarayabilecek kullanıcı kimliği çevirisi yapmak için bir yol olmadan kullanıcı düzeyinde verilere erişmesi gereken durumlarda, geliştirici platformu API'si birden çok kullanıcı belirtecini yönetecek şekilde ayarlanabilir. Örneğin:

1. Geliştirici platformu API'si, aşağı akış sistemleriyle kullanılmak üzere sağlayıcıya özgü kullanıcı belirteçlerinin önbelleğini destekleyebileceğinden.
2. API tarafından tetiklenen belirli bir sağlayıcıyla yapılan tüm etkileşimler, varsa sağlayıcının kullanıcı belirtecinde yer alır.
3. Kullanılabilir kullanıcı belirtecinin olmadığı durumu işlemek için sağlayıcı bir OAuth akışı tetikler ve bir tane alır.
4. Başlamak için geliştirici platformu API'si, sağlayıcıya geçirilen bir yeniden yönlendirme URI'sine sahip bir OAuth akışı için kimlik doğrulama URI'sini geri geçirir. geçirilen URI bir nonce / tek kullanımlık kod içerebilir.
5. Ardından API, URI ile "kimliği doğrulanmamış" bir yanıt döndürür.
6. Daha sonra herhangi bir UX, tarayıcıda uygun kimlik doğrulama akışını yönlendirmek için bu URI'yi kullanabilir.
7. Yeniden yönlendirme işlemi gerçekleştiğinde geliştirici platformu gerekli kullanıcı belirtecini alır ve kullanıcı kimliğiyle birlikte daha sonra başvurmak üzere önbelleğe alır.
8. İstemci daha sonra API çağrısını yeniden deneyebilir ve bu da başarılı olur.

Bu kavram, kimlikleri mümkün olduğunca yeniden kullanabileceğiniz ve aşağı akış sistemi başına ayrı yeniden yönlendirme URI'leri bulundurmanız gerekmediğinden karmaşık kimlik doğrulamasıyla başa çıkmanın bir yolunu özetler.

Verileri toplama ve ek özellikler sağlama

Araçlara ve raporlama sistemlerine bağlam bilgisi olan ayrıntılı bağlantılar kullanma

Bu noktaya kadar sorun alanının otomasyon açısından konuşuyorduk. Kullanıcı arabiriminiz otomasyon sırasında döndürülen varlıklardaki değerleri kullanarak ekip için diğer sistemlere ayrıntılı bağlantılar oluşturabildiğinden bu tek başına uzun bir yol olabilir.

Otomasyonla ilgili olmasa bile geliştirici platformu sağlayıcıları her türlü varlık gereksinimini yayabilir. Ancak, genel olarak tüm şirket içi geliştirici platformunuzun tüm ayrıntılı verilerini geliştirici platformu grafınıza getirmek istemezsiniz. Grafana, Prometheus, DataDog veya SonarQube gibi ürünlerde kod zekası gibi gözlemlenebilirlik çözümlerindeki panoların ve GitHub ve Azure DevOps gibi DevOps paketlerindeki yerel özelliklerin tümü çok yeteneklidir. Bunun yerine, en iyi yaklaşım genellikle bu diğer sistemlere ayrıntılı bağlantılar oluşturmaktır. Varlıklarınız, günlük içeriği gibi ayrıntılı bilgileri doğrudan içermeden bağlantılar oluşturmak için yeterli bilgi sağlayabilir.

Araçlar arasında toplanan ve özetlenen verileri istediğiniz veya özel ölçümler oluşturmanız gereken durumlar için power BI veya Microsoft Fabric raporlama çözümleri bir sonraki çağrı bağlantı noktanız olabilir. Ekip verilerini birleştirmek için, Foundation'ınızın veritabanına bağlanabilir veya geliştirici platformu API'sini kullanabilirsiniz. Örneğin, Planlama ve öncelik belirleme bölümünde açıklandığı gibi, özel bir panonun olmasını isteyebileceğiniz bir yer, iç geliştirici platformunuzun başarısını ölçmektir.

Oluşturduğunuz her ek deneyimde seçici olun

Ortak bir portal gibi bir uygulamada mevcut özellikleri yeniden oluşturmak cazip olsa da, bunu da korumanız gerektiğini unutmayın. Bu, bir ürün düşünce yapısına uymanın önemli olduğu alandır. Pano stili arabirimlerini kavramak ve anlamak kolaydır, ancak geliştiricileriniz başka bir yerde daha fazla değer bulabilir.

Buna göre buradaki model, özel kullanıcı deneyimleri oluşturmak için geliştirici platformu grafında toplanan verileri kullanmanıza olanak tanır. Varlıkların bir kullanıcı veya takıma bağlanabilmesi için yerleşik desteğe sahip olması gerekir. Bu, geliştirici platformu API'nizin çıkışı kapsamasına olanak tanır (dizin oluşturma ve önbelleğe alma ile birlikte).

Ancak, ayrıntılı bir bağlantı yerine özel UX oluşturmanız gerektiğinde bile, tüm verileri geliştirici platformu grafınıza çekmek genellikle en iyi yaklaşım değildir. Örneğin, UX'inizde zaten iyi tanımlanmış ve yönetilen bir giriş sayfası olan günlükleri görüntülemek isteyebileceğiniz bir durum düşünün. UX'nizin doğrudan aşağı akış sistemlerinden bilgi toplamasına yardımcı olmak için ilgili varlıklardaki bilgileri kullanın.

Başlamak için, bağlanmak için sistemden sisteme tümleştirme kullanmanız gerekebilir, ancak kullanıcılar ve ekiplerde açıklanan modellerden birini uyguladıktan sonra, depolanan tüm aşağı akış kullanıcı/ekip kimliklerini veya gerekirse kullanıcı kimlik doğrulama belirteçlerini kullanabilirsiniz.

Aşağıda dikkate alınması gereken bazı yaygın deneyim örnekleri verilmiştir:

Örnek	Açıklama
Keşif ve keşif	Bir platform mühendislik uygulayıcısı tarafından "Projeleri yavaşlatan şey, geliştirici becerileri değil iletişimdir." –Daniel, Bulut Mühendisi, Fortune 500 Media Company. Yazılım bir takım sporu olduğundan, ekipleri ve sahip oldukları varlıkları keşfetmeye yardımcı olacak bir kullanıcı arabirimi oluşturmak genellikle ilk ele alınacak şeylerden biridir. Ekipler arası arama, bulma ve belgeler, yeniden kullanımın desteklenmesine yardımcı olur ve iç kaynak veya destek için işbirliğine yardımcı olur. Ekipler ayrıca ortamlar, depolar ve belgeler gibi diğer kaynaklar da dahil olmak üzere sahip oldukları şeyleri bulmak için tek noktadan alışveriş yapma avantajından da yararlanırlar.
Ortamların veya kaynakların el ile kaydı	Geliştirici platformu düzenleyicisi aracılığıyla birçok şey sağlanıp izlense de, zaten var olan veya henüz otomatik olmayan kaynakları veya ortamları da kaydetmek isteyebilirsiniz. Git deposundan bilgi alan ve kaynaklara/ortam yönetimine bilgi ekleyen basit bir sağlayıcı burada yararlı olabilir. Zaten bir yazılım kataloğunuz varsa bu, bunu modelle tümleştirmenin bir yolu da olur.
API kataloğu	Geliştiricilerin kullanması gereken API'leri izleme uzun bir yol kat edebilir. Henüz bir şeye sahip değilseniz, API'leri ve bunların durumunu temsil eden bir dizi dosya içeren basit bir Git deposuyla bile başlayabilir, onay iş akışınızı yönetmek için PR'leri kullanabilirsiniz. Bunlar, görüntülenebilmeleri veya diğer varlıklarla ilişkilendirilebilmeleri için geliştirici platformu grafınıza eklenebilir. Daha güçlü özellikler için Microsoft'un API Center veya başka bir ürünü gibi özellikleri tümleştirebilirsiniz.
Lisans uyumluluğu	Bazı durumlarda, yazılım lisansı uyumluluğu ve bilgisayar lisansı tüketimi hakkında görünürlük sağlamak da isteyebilirsiniz. Geliştirici platformları ayrıca koltukları tüketmek için gereken otomasyonu ekleyebilir, ancak koltuklar el ile atanmış olsa bile (örneğin Git deposundaki bir çekme isteği işlemi aracılığıyla), sahip oldukları öğelere geliştirici görünürlüğü (ve yöneticinin her şeyi görme yeteneği).
Kubernetes'in uygulama merkezli görünümü	Paylaşılan bir Kubernetes kümesi kullandığınızda, geliştiricilerin küme yöneticisi UX aracılığıyla uygulamalarının durumunu bulması ve anlaması zor olabilir. Farklı kuruluşlar bu sorunu farklı şekilde ele almayı tercih etmiştir, ancak bir uygulamayı temsil etmek için ad alanı kullanmak bunu yapmak için iyi bilinen bir yoldur. Buradan, kümedeki uygulamanın ad alanı ile bir ekip arasında ilişki kurmak ve uygulama için daha geliştirici odaklı bir durum görünümü oluşturmak ve diğer araçlara veya web kullanıcı arabirimlerine ayrıntılı bağlantılar sağlamak için varlıkları kullanabilirsiniz.

Kullanıcı deneyimleri

Kuruluşunuzdaki farklı roller, günlük çalışmaları için ağırlık merkezini temsil eden araçlara veya hizmetlere sahip olacaktır. Bu sistemlerin çekilmesi, bu yer çekimi merkezleri dışındaki yeni kullanıcı deneyimlerinin çekiş kazanmasını zorlaştırabilir. Mükemmel bir dünyada geliştiriciler, operasyonlar ve diğer roller genellikle zaten kullandıkları, kendileri için anlamlı olan bir ortamda çalışmaya devam edebilir.

Bunu göz önünde bulundurarak, platform mühendisliği yolculuğunuzda ilerlerken birden çok kullanıcı arabirimini planlamak iyi bir fikirdir. Bu, basit bir başlangıç yapma, değeri kanıtlama ve ihtiyaç ortaya çıktıkçe daha karmaşık arabirimlere doğru büyüme fırsatı da sağlayabilir.

Sahip olduğunuz her şeyi tümleştirin

Yazılım mühendisliği sistemlerini uygulama ve Uygulama platformunu geliştirme makalelerini okuduysanız, büyük olasılıkla kullanmaya devam etmek istediğiniz sistemleri tanımlamışsınızdır. Her iki durumda da sıfırdan yeni deneyimler oluşturmaya başlamadan önce sahip olduğunuz şeyleri geliştirip geliştiremeyeceğinizi değerlendirin. (Kendinize sorun, insanlar başka bir yeni kullanıcı deneyimine mi yoksa sahip oldukları bir şeyin geliştirilmiş bir sürümüne mi daha iyi tepki verecek?)

Kullanmaya devam etmek istediğiniz araçlardan, yardımcı programlardan veya web uygulamalarından bazıları özeldir ve bunlar geliştirme için iyi adaylardır. Ancak sık kullandığınız araç ve hizmetlerin kullanabileceğiniz bir genişletilebilirlik modeline sahip olup olmadığına dikkat edin. Buradan başlayarak çok fazla avantaj elde edersiniz. Bu, bakım ve güvenlik sorunlarını ortadan kaldırır ve çözmeye çalıştığınız soruna odaklanmanızı sağlar

Örneğin, kullanmakta olduğunuz aşağıdaki yüzeyleri genişletebilirsiniz:

• Düzenleyiciler ve IDE'ler.
• DevOps paketiniz.
• CLI'ler de giderek genişletilebilir.
• Power Pages gibi düşük/kodsuz ortamlar.

Her biri belirli bir rol için sıfırdan ayarladığınız bir şeyden daha iyi bir başlangıç noktası sağlayabilir çünkü bunlar mevcut ağırlık merkezleridir. Temel olarak ortak bir geliştirici platformu API'sine sahip olmak, zaman içinde öğeleri değiştirmenizi, deneme yapmanızı ve değiştirmenizi sağlar.

Geliştirici portalı oluşturmak için web düzenleyicisi uzantılarını göz önünde bulundurun

Geliştiriciler için web tabanlı bir deneyim arıyorsanız, yeni bir eğilimin düzenleyicilerin ve IDE'lerin web tabanlı sürümleri olduğunu unutmayın. VS Code kullananlar gibi çoğu, uzantı desteğine sahiptir. VS Code ile bu web deneyimleri için oluşturduğunuz her şey, çift avantaj için yerel olarak çevrilir.

GitHub Codespaces gibi hizmetlerin ötesinde vscode.dev, VS Code düzenleyicisinin işlem içermeyen ücretsiz bir web sürümüdür, ancak özel kullanıcı arabirimi için web görünümlerini kullananlar da dahil olmak üzere belirli uzantı türleri için destek içerir.

Geliştiricileriniz VS Code'un kendisini kullanmıyor olsa bile, UX desenleri iyi bilinir ve diğer geliştirici araçlarında bulunabilir. vscode.dev kullanmak, aracın kendisine ek olarak geliştirici deneyimleri için kullanışlı ve tanıdık bir web tabanlı temel sağlayabilir.

Bunlar, yerel kullanıma da çevrilebilecek tanıdık bir biçimde geliştirici odaklı portal görevi görebilir.

ChatOps

Genellikle göz ardı edilen bir diğer fırsat da ChatOps arabirimini uygulamaktır. ChatGPT veGitHub Copilot gibi yapay zeka ürünlerinin artması nedeniyle sohbet tabanlı arabirimlerin artması göz önünde bulundurulduğunda, eylem komutları veya eğik çizgi komutları otomasyon iş akışlarını tetiklemenin, durumu denetlemenin ve daha fazlasının yararlı bir yolunu sağlayabilir. Çoğu uygulama CI/CD platformunun Microsoft Teams, Slack veya Discord gibi sistemler için kullanıma hazır desteği olduğu düşünüldüğünde, bu, geliştiricilerin her gün kullandığı başka bir kullanıcı arabirimi ve ilgili işlem rolleri ile tümleştirmenin doğal bir yolu olabilir. Ayrıca tüm bu ürünlerin genişletilebilirlik modeli vardır.

Yeni bir geliştirici portalına yatırım yapma

Temel olarak kullanmak istediğiniz mevcut bir portalınız veya arabiriminiz olmadığını varsayarsak, yeni bir geliştirici portalı oluşturmaya karar vekleyebilirsiniz. Bunu başlangıç noktası yerine bir hedef olarak düşünün. Sizinle çalışan bir geliştirme ekibiniz yoksa, bu çabayı başlatmanın tam zamanıdır. Her kuruluş farklıdır, bu nedenle bu tür bir deneyimde olması gerekenler için herkese uygun bir yanıt yoktur. Sonuç olarak, bugün böyle bir şey için olduğu gibi kullanabileceğiniz önceden paketlenmiş bir ürün için hiçbir defacto yanıtı yoktur.

Özel yerleşik şirket içinde barındırılan seçenekler için genel web portalı çerçeveleri yeni değildir ve geliştirme ekipleriniz zaten kullanabileceğiniz bir çerçeve kullanıyor olabilir. Erken geri bildirim için kullanıcılarınızın önünde bir şeyler çıkarmaya çalışıyorsanız, ortak geliştirici platformu API'sine bağlanmak için düşük kodlu Power Pages kadar basit bir şeyle bile başlayabilirsiniz.

Daha yeni geliştirici portalı eforları daha fazla düşünceye bağlıdır. Örneğin , Backstage.io başlangıçta Spotify'ın ihtiyaçlarını karşılamak için oluşturulmuş özel bir geliştirici portalı araç setidir. Create-react-app uygulamasının React.js için yaptığı gibi kaynak ağacınızı önyüklemenize yardımcı olacak bir CLI içerir.

Portal araç seti olarak, çalışmaya başlamak için çalışma gerekir ve özelleştirme için TypeScript, Node.js ve React bilgisi gerekir. Bununla birlikte, bunun en harika yanı, bir araç seti olarak neredeyse her şeyi değiştirebilmenizdir. Kendi yazılım kataloğuna ve şablon oluşturma mekanizmasına da sahiptir, ancak kullanımları gerekli değildir ve eklentiler olarak adlandırılan yeni 1^st ve 3^rd taraf kodunu getirmenin iyi tanımlanmış bir yoluna sahiptir.