Geliştirici öz hizmet temeli tasarlama

Mühendislik sistemleriniz için hedefinizi iyi anladıktan sonra daha gelişmiş geliştirici self servis deneyimleri oluşturabilirsiniz. Geliştirici self servis deneyimi kavramlar, desenler ve bileşenler temeli üzerine kurulmuştur.

Bugün kuruluşunuzda açıklanan her şeye ihtiyacınız olmayabilir ancak özel bir şey oluşturursanız veya ilgili ürünleri değerlendirirseniz bu kavramları aklınızda tutmalısınız. Geliştirici self servis deneyim modeliniz 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, burada açıklanan modelin bazı öğeleri için farklı terimler kullanabilir, ancak model sizi yönlendirmeye yardımcı olabilir.

İş akışlarını otomatikleştirme, verileri toplama, basit bir başlangıç ve aşamalı olarak genişletme

Amacınız, denetimli, idare edilen görev yürütme ve sağlama ile birlikte merkezi görünürlük aracılığıyla korumalar ile self servis etkinleştirmektir. Odaklanmak için en değerli olan alanlar, ya yorucu olanlar ya da geliştiricinin karmaşıklık veya izinler nedeniyle kendi başına yapamayacağı şeylerdir. Bu son kısım, manuel bir hizmet masası süreciyle 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ştirilmesi gerekebilir. 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' (üzerine artık destek sunulmayan yazılımlar) ile ilgileniyor... Standartlaştırma genellikle otomatik işlemlerin olası kesintisi ve gerekli değişiklikleri tanımlamanın zaman alan görevi nedeniyle elde edilemeyebilir. - Martin, DevOps mühendisi, büyük lojistik şirketi

Hızlı bir şekilde yeni veya güncelleştirilmiş bir standarda 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 birleşimi 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 denemelere izin vermek isteyeceksiniz.

Self servis deneyimleri genellikle iki birincil kategoriye ayrılır: otomasyon ve veri toplama.

Veri toplama iyi kullanıcı deneyimleri oluştururken otomasyon daha önemlidir:

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

Platform mühendisliği yolculuğunuzda, otomasyonla çözülmüş olabilecek sorunları belirlediniz. Otomasyon, bilişsel yükü ve geliştiricinin yükünü azaltmanın ötesinde, uygulamaların işlerini yapmak için operasyonlar, güvenlik ve diğer roller için en iyi araçlara ve hizmetlere 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. 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, atıkları denetleme, idare ve 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 olarak görünen el ile bir iş akışı işlemini de tetikleyebilir ve kolaylaştırabilirsiniz. Bu, platformunuzun ilk aşamalarında, ekosisteminize getirdiğiniz yeni ürünlerde veya bir sistem kullanarak otomatikleştirmediğiniz veya otomatikleştiremediğiniz alanlarda (örneğin, yazılım lisansı ataması) yararlıdır. Doğru tasarımla, zaman içinde tamamen otomatik bir süreç akışına geçtiğinizde, Power Automate gibi araçlarla desteklenen manuel bir süreçle başlayabilirsiniz. Bu nedenle, başlangıçtan itibaren bir otomasyon tasarla.

Mühendislik sistemleriniz veya bir iç portal gibi mevcut yatırımları yeniden kullanarak basit bir başlangıç yapın, ardından CLI'ler, temel web sayfaları, hatta Power Pages, Power BI veya Microsoft Fabric panoları oluşturmaya geçin ve ihtiyaç duyulduktan sonra genişletin. 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.

Geliştirici self servis platform bileşenleri: API, graf, düzenleyici, sağlayıcılar ve meta veriler

Geliştirici self servisinin temellerini 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	Description
Geliştirici platformu API'si	Kullanıcı deneyimleri için tek iletişim noktanız. Bu, sistemin diğer sistemlerle olan sözleşmesini etkili bir şekilde ifade eder.
Geliştirici platformu grafiği	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 orkestratörü	Bir sistemde veya el ile gerçekleştirilen bir işlemle 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ştirilebilen 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 veya şablon tabanlı eylem isteklerini yerine getirmek 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ürleri yayar.
Kullanıcı profili ve ekip meta verileri	Geliştirici platformu API'sine erişim ve gruplandırma amacıyla kavramsal bir ekibe bağlı bir grup kişi hakkındaki bilgilerin kalıcı hale getirilmesi 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 bir ekip ilgili aşağı akış sistemi temsillerine bağlanabilir. Bu bilgi deposunun bir uygulaması, geliştirici platformu grafını yeniden kullanmaktır. Geliştirici kendi kendine hizmet sistemi, hem kullanıcı hem de ekip için ortak bir varlık türü oluşturabilir ve bu bilgileri graf içinde kalıcı hale getirebilir. Ancak, burada açıklık sağlamak için bu mağazayı ayrı tutacağız.

Bu temel bileşenler, zaman içinde farklı yapı taşlarını kullanmanızı ve değiştirmenizi sağlar.

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

Hayır. İlk olarak, bu, böyle bir temel yapıldıktan sonra neler yapabilmesi gerektiğini düşünmenize yardımcı olacak kavramsal bir modeldir. İkincisi, 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 bunun daha düşük bir öncelik olduğunu söylediğinden, bu özellikleri atlayabilirsiniz. Sahip olduğunuzla başlayın ve büyüyün.

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, 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 görür. 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 tanımlamanız gerekir. Otomasyon ve veri toplama gibi temel işlevlerin, iyi tanımlanmış arabirimlere sahip takılabilir bileşenlerle etkileşim kurarak sağlanması fikridir. Bu gevşek bağlantı, ihtiyacınız olanı artımlı olarak bağlamanıza yardımcı olur ve işlevselliği temelin geri kalanından bağımsız olarak test edebilirsiniz.

Ayrıca, platformunuz için ölçeklenebilir bir iç kaynak zihniyetini etkinleştirmenin de önemli bir yoludur. Genellikle, platform mühendisliğiyle ilgili iç kaynak kullanımı, sürekli bakım zorlukları nedeniyle ivme kazanamaz. 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 koruma ve hatta çekme isteklerini gözden geçirme kapasitesi sınırlıdır. Geliştirici platformu sağlayıcısı kavramı, bağımsız olarak yazılmış kodun geliştirici self servis temelinizdeki temel işlevlere bağlanmasını sağlayarak bu gerilimi hafifletir. Hangi sağlayıcıları kullandığınızı dikkatle yönetmeniz, sağlayıcı kodlarını 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ı

Entities

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 şeydir. Varlıklar, bir araya getirildiğinde iç geliştirici platformunuzun parçaları hakkında kritik bilgiler sağlayan bir graf oluşturan birbirleriyle ilişkilere sahip olabilir. Geliştirici platformu sağlayıcıları aşağıdakiler dahil olmak üzere temel özellikleri etkinleştirmek için varlıkların çıktısını alabilir:

• Bulma ve kullanım için dışarıdan sağlanan kaynakları/ortamları veya kullanılabilir API'leri bulma
• Bağımlılık analizi, etki analizi, bulma vb. için ilişkileri ortaya çıkarma.
• Keşif ve işbirliği için bakımcı / sahiplik bilgilerini görünür hale getirme
• Kullanıcı deneyimlerinde kullanmak için daha fazla veri ekleme

Bu işlevin iyi tanımlanmış bir geliştirici platformu sağlayıcı arabiriminde kapsülleştirilmesi tümleştirmeyi ve testi kolaylaştırır, bağımsız dağıtıma olanak tanır ve birincil iç geliştirici platformu ekibi dışındaki geliştiricilerin sağlayıcılara katkıda bulunmasına ve 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, temelin bunları yönetmesine izin vermek için bir ortak özellikler kümesine sahip olması gerekir. Dikkate alınması gereken bazı özellikler şunlardır:

• Benzersiz tanımlayıcı
• İsim
• Kaynak sağlayıcı
• İsteğe bağlı ilişkilendirmeler:
  • Sahip 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'yi baştan dahil etmek, güvenlik ve zaman içinde iç geliştirici platformunuzu büyütmek için kritik öneme sahiptir. 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
• Kaynaklar
• API’ler
• Depoları
• Components
• Tools

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ı topografyasının ayrıntılarını eklemeniz gerekmez; Yalnızca 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 birleştirmeyi mümkün kılmanın temel unsuru olan keşif için başlangıç noktaları sağlar.

Diğerleri belirli bir kullanım örneğine veya sağlayıcıya özgü olduğundan, zaman içinde büyüyen bir varlık türü kümesini nasıl barındırabileceğinizi düşünmelisiniz.

Şablonlar

Bu bağlamdaki bir şablon kavramı, bir eylem gerçekleştirmeye yönelik varlıklar 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ırma gibi her şeyden isteğe bağlı eklemelere kadar değişebilir.

Şablon örnekleri şunlardır:

• Kod olarak altyapı (IaC) şablonları
• Uygulama şablonları (sağdan başla) 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ı (örneğin, HTTP isteğinin tetiklediği bulut akışı)
• E-posta ş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.

Asıl şablon ayrıntılarının merkezi olarak depolanmasına gerek yoktur. 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 Artifact Registry'de 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ı şablonları yazar ve yeniden kullanmak üzere geliştirme ekipleriyle paylaşır. Bu şablonların bir sistem aracılığıyla kullanımını merkezileştirmek, geliştirici self servisini sağlar ve kuruluş standartları veya ilkeleriyle uyumluluğu zorunlu kılmaya yardımcı olan korumalar oluşturur. Geliştirici platformu düzenleyicisini birazdan ele aldığımızda bu konuda daha fazla bilgi edinebilirsiniz.

Geliştirici platformu grafiği

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 grafik olarak düşünebilirsiniz. Ancak, varlıklar için gerçek verilerin doğrudan grafiğe ö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ınabiliyor.

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ım ve ortamları otomatik olarak entegre etmek de isteyebilirsiniz. Zaman içinde farklı dağıtım sistemleri arasında geçiş yapabilir ve 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 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, bir geliştirici platformu sağlayıcısı tarafından gerçekleştirilen tüm eylemlerin aynı API'ye sağlanan varlıklara otomatik olarak katkıda bulunması için aynı grafiktekinden yararlanabilir.

Geliştirici platformu düzenleyici

Geliştirici platformu düzenleyici, 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 koordine eder. 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.

Düzenleyici olarak GitHub Actions, Azure Pipelines veya başka bir iş akışı altyapısı 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 yanıp sönmek zorunda 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 eskileri etkilemeden yeni altyapıyı yeni eylemlere geçirebilirsiniz.
• Düzenlemeye yardımcı olmak istediğiniz bazı işlemler, daha sonra tamamen otomatikleştirmeyi planlasanız bile başlangıçta el ile adım atılmasını gerektirebilir.
• Diğer eylemler, ödenecek 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 işlemler, GitHub Actions veya Azure Pipelines kadar yetenekli bir hizmeti başlatmanın gerekmediği veya ölçeklendirme açısından maliyet etkin olmadığı durumlarda basit HTTP istekleri aracılığıyla işlenebilir.

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

Genel kavram şu şekildedir:

• Şablonlar isteğe bağlı olarak kullanıcının girebileceği bir giriş kümesi belirtebilir. Bir geliştirici belirli bir eylemi tetiklediğinde, bir şablon seçer (bu şekilde açıklanmasa bile) ve herhangi bir giriş girer.
• Şablonla ilgili girişlere başvuru, geliştirici platformu API'sinde bir istek haline gelir.
• İ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şeni, istekteki şablonu, şablonun kaynaklandığı geliştirici platformu sağlayıcısına yönlendirir.
• Ardından geliştirici platformu sağlayıcısı uygulaması için uygun adımları gerçekleştirir.
• (İsteğe bağlı) Geliştirici platformu sağlayıcısı, eylemi gerçekleştirirken istek durumunu güncelleştirir.
• İstek karşılandıktan sonra geliştirici platformu sağlayıcısı, geliştirici platformu grafiğine eklemek veya 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, geliştirici platformu sağlayıcıları daha gelişmiş etkileşimleri desteklemek için doğrudan geliştirici platformu API'sini çağırarak giriş olarak daha fazla varlık alabilir ve hatta başka bir ilgili eylem isteyebilir.

Genel bir görev veya iş akışı altyapısı kullanan bir geliştirici platformu sağlayıcısı seçin. Daha açık belirtmek gerekirse, Yazılım mühendisliği sistemlerini uygulama kapsamında bir araya getirdiğinizde köprü oluşturacak bir şey istiyorsunuz. Yatırım yapılabilecek genel bir iş akışı veya görev yürütme altyapısı bir CI/CD sistemidir.

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

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

GitHub Actions için bu işin anahtarı, geliştirici platformu sağlayıcısının belirtilen GitHub örneğine bağlanabilmesi ve Actions REST API'yi kullanarak bir iş akışı çalıştırmasını başlatmak için bir iş akışı dağıtım olayını tetikleyebilmesidir. 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 Pipeline 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 veya 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:

• Platform mühendisleri veya DevOps ekip üyeleri, geliştiricilerin erişim izni olmadığı halde geliştirici platformu sağlayıcısı tarafından kullanılmak üzere ayarlanmış bir veya daha fazla merkezi depoda iş akışlarını/bantlarını koruyabilir. Bu depo, iş akışlarının/işlem hatlarının kullandığı betikleri ve IaC parçacıklarını içerebilir.
• 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ın ayrıntıları için GitHub Actions ve Azure DevOps belgelerine bakın veya Azure Key Vault gibi bir şey kullanarak gizli dizileri merkezileştirmeyi tercih edebilirsiniz.
• Bu iş akışları/işlem hatları daha sonra elde edilen varlıkları derleme/dağıtım yapıtı (GitHub belgeleri, Azure DevOps belgeleri) olarak yayımladıkları bir modeli izleyebilir.
• Bir çalıştırma sırasında geliştirici platformu sağlayıcısı iş akışının/işlem hattının durumunu izleyebilir 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.
• Tamamlandıktan sonra sağlayıcı, geliştirici platformu grafiğine eklemek amacıyla yayımlanan artifaktı gerektiği gibi 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 çıkaracak şekilde ayarlayabilirsiniz.

CI/CD sistemi kullanmanın en iyi özelliği, 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ği için geçerlidir. 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

Şablonları işleyebilen diğer geliştirici platformu sağlayıcılarının bazı örnekleri aşağıda verilmiştir.

Example	Description
Kaynak denetimi işlemleri	Bazı durumlarda depo oluşturmanız veya güncelleştirmeniz, çekme isteği göndermeniz veya kaynak denetimiyle ilgili başka bir 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 ç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 ve güvenli bir şekilde etkinleştirmeye daha doğrudan odaklanır. Diğer örnekler arasında 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 örnekler verilebilir. Kendi CLI'lerine sahip deneysel Radius OSS kuluçka projesi gibi uygulama merkezli modellerin bile 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 öncülük ettiği önemli bir parçasıdı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 yapı 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	İster el ile onay için otomatik olarak bir PR oluşturma, ister Power Platform gibi bir şey kullanarak yanıt vermek üzere geliştirici olmayan kişiler için el ile iş akışı adımları oluşturma, aynı şablon tabanlı model bir geliştirici platform 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 ihtiyacınız olmasa da, geliştirici platformu sağlayıcısı gibi bir şey aracılığıyla genişletilebilirlik özelliğinizin zaman içinde otomasyon özelliklerinizin 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 ilişkidir, bu nedenle self servis bir temelin bu sistemleri bir araya getirmeyle ilgili daha zorlu sorunları nasıl ele alması gerektiğini planlamak önemlidir. Kimlik, kullanıcı ve ekiplerle ilgili yaygın sorunları aşmaya yönelik bir strateji aşağıdadır.

Tavsiye	Description
En iyi güvenlik için geliştirici platformu API'sini doğrudan kimlik sağlayıcınızla tümleştirin.	Geliştirici platformu API'sinin güvenliğini sağlamak için, sağlam kimliği ve Entra Id'nin RBAC özellikleri göz önünde bulundurularak 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 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 kullanın.	Ç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ı gruplarını (AD grupları gibi) bağlamak için SCIM gibi protokollerinin desteklerinden faydalanmaya dikkat edin. 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'un da benzer özellikleri vardır.

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 RBAC ve veri toplama için bir ekip kavramı oluşturmak için birden çok grubun gerçekten bir araya gelmesi gerektiğini fark edersiniz.

Platform mühendisliği bağlamında, bir ekibi birlikte çalışan farklı rollere sahip bir grup kişi 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 (TAC) deseni olarak kullanıyorsanız geliştirici platformu sağlayıcısı depodaki dosya değişikliklerini izleyebilir ve bunları bir kullanıcı profilinde ve ekip meta veri deposunda önbelleğe alabilir. İsterseniz, bu çekirdek RBAC yapılarını zaten mevcut olan bir Azure Dev Center Projesi ile 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 doğrudan kimlik sağlayıcısı kavramlarını yerel olarak tümleştirip kullansa da, birçoğu bunu bir grup veya kullanıcının (SSO ile bile) kendi temsili olarak soyutlar. Bu gerçeklik, araçlar arasında erişimi etkinleştirmenin ötesinde veri toplama için de sorun oluşturabilir. Ö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 (örneğin, Entra Kimliği'ndeki Nesne Kimliği doğrudan kullanılmaz). Bu, farklı kimlikler arasında eşleme yapılmadığı 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 alın

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 aralarında eşleme yapmanızı sağlayabilir. Özetlemek gerekirse, güvenli, denetlenebilir bir Git deposu bir ekibin kaynağı haline gelir ve PR'ler güncelleştirmeleri yapmak için denetimli bir kullanıcı arabirimi sağlar. CI/CD sistemleri daha sonra alıcı sistemleri güncelleyebilir ve bunu yapmak için kullandığı ekip ile ilgili tanımlayıcı ilişkilerini kalıcı olarak saklayabilir.

Ö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ı genel kavram aynı şeyi gerçekleştirmek için geliştirici platformu düzenleyici kullanılarak da 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ği için 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 sistemde 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ı önbelleğe almanız gerekebileceğinden bu durum karmaşık olabilir.

Birden çok kullanıcı belirteci kullanmaya geri dönün

Sağlayıcıların işe yarayabilecek kullanıcı kimliği çevirisi yapmadan 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:

• Geliştirici platformu API'si, aşağı akış sistemleriyle kullanılmak üzere sağlayıcıya özgü kullanıcı belirteçlerinin önbelleğini destekleyebilir.
• 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.
• Kullanılabilir kullanıcı belirtecinin olmadığı durumu işlemek için sağlayıcı bir OAuth akışı tetikler ve bir tane alır.
• 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 gönderir. Geçirilen URI, bir nonce / tek seferlik kullanım kodu içerebilir.
• Ardından API, URI ile kimliği doğrulanmamış bir yanıt döndürür.
• Daha sonra herhangi bir UX, tarayıcıda uygun kimlik doğrulama akışını yönlendirmek için bu URI'yi kullanabilir.
• Yeniden yönlendirme işlemi gerçekleştiğinde geliştirici platformu gerekli kullanıcı belirtecini alır ve kullanıcı kimliğiyle birlikte gelecekte başvurmak üzere önbelleğe alır.
• İstemci daha sonra API çağrısını yeniden deneyebilir ve bu da başarılı olur.

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

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 kat edebilir.

Otomasyonla ilgili olmasa bile geliştirici platformu sağlayıcıları gereken her tür varlığı yayabilir. Ancak, genel olarak tüm iç geliştirici platformunuz genelindeki tüm ayrıntılı verileri geliştirici platformu grafınıza getirmek istemezsiniz. Grafana, Prometheus, veya DataDog gibi gözlemlenebilirlik çözümlerindeki panolar, SonarQube gibi ürünlerdeki kod zekası yetenekleri ve GitHub veya Azure DevOps gibi DevOps paketlerindeki yerel özelliklerin tümü oldukça 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, kayıt 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 toplanmış ve özetlenmiş veriler istediğiniz veya özel ölçümler oluşturmanız gereken durumlarda, raporlama çözümleri Power BI veya Microsoft Fabric bir sonraki çağrı bağlantı noktanız olabilir. Ekip verilerini birleştirmek için, kuruluşunuzun veritabanına bağlanabilir veya bir geliştirici platformu API'si aracılığıyla gidebilirsiniz. Örneğin, Planlama ve öncelik belirleme bölümünde açıklandığı gibi, özel bir pano almak isteyebileceğiniz bir yer, iç geliştirici platformunuzun başarısını ölçmektir.

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

Mevcut özellikleri ortak bir portalda 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 arabirimleri kolayca tasarlayabilir ve anlayabilirsiniz ancak geliştiricileriniz başka yerlerde 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, derin 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, zaten iyi tanımlanmış ve yönetilen bir giriş sayfası olan UX'inizde log dosyalarını görüntülemek isteyebileceğiniz bir durumu 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:

Example	Description
Keşif ve Araştırma	Bir platform mühendislik uygulayıcısı olarak "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 gerekenlerden biridir. Ekipler arası arama, bulma ve belgeler, yeniden kullanımın desteklenmesine yardımcı olur ve iç kaynak oluşturma veya destek için işbirliğine yardımcı olur. Teams ayrıca ortamlar, depolar ve belgeler gibi diğer kaynaklar dahil olmak üzere sahip oldukları öğeleri bulmak için tek bir mağazaya sahip olmanın avantajından da yararlanır.
Ortamların veya kaynakların el ile kaydı	Geliştirici platformu düzenleyici aracılığıyla birçok şey sağlanıp izlense de, zaten var olan veya henüz otomatikleştirilmiş 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 da bunu modelle tümleştirmenin bir yolu haline gelir.
API kataloğu	Geliştiricilerin kullanması gereken IZLEME API'leri 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 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 API Center veya başka bir ürün gibi bir özelliği tümleştirebilirsiniz.
Lisans uyumluluğu	Bazı durumlarda, yazılım lisans uyumluluğu ve lisans tüketimi hakkında görünürlük sağlamak da isteyebilirsiniz. Geliştirici platformları, lisansları kullanmak için gereken otomasyonu da ekleyebilir, ancak lisanslar elle atanmış olsa bile (örneğin, Git deposundaki PR süreci aracılığıyla), geliştiricilerin sahip oldukları konulara dair görünürlüğü olması (ve yöneticilerin her şeyi görebilmeleri).
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 edebilir, ancak bir uygulamayı temsil etmek için ad alanı kullanmak iyi bilinen bir yöntemdir. Buradan, kümedeki uygulamanın ad alanı ile bir ekip arasında ilişkilendirmeler kurmak ve uygulama için daha geliştirici odaklı bir durum görünümü oluşturmak ve diğer araçlara veya web URI'lerine 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 sahiptir. Bu sistemlerin çekim gücü, bu çekim 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 kendileri için anlamlı olan ve çoğunlukla zaten kullandıkları bir ortamda çalışmaya devam edebilir.

Bunu göz önünde bulundurarak, platform mühendislik yolculuğunuzda ilerledikçe 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 şeyleri 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 avantajlı olacaksınız. 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/kod içermeyen 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 gerektirmeyen ücretsiz bir web sürümüdür, ancak özel kullanıcı arabirimi için web görünümleri kullananlar da dahil olmak üzere belirli uzantı türleri için destek içerir.

Geliştiricileriniz VS Code'un kendisini kullanmasa 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 çevrilebilen tanıdık bir biçimde geliştirici odaklı bir portal görevi görebilir.

ChatOps

Genellikle göz ardı edilen bir diğer fırsat da Bir ChatOps arabirimi uygulamaktır. ChatGPT ve GitHub 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ğe sahip olduğu düşünüldüğünde, bu, geliştiricilerin ve ilgili operasyon rollerinin her gün kullandığı başka bir kullanıcı arabirimiyle tümleştirmenin doğal bir yolu olabilir. Ayrıca, bu ürünlerin tümü genişletilebilirlik modeline sahiptir.

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şlatmak için tam zamanı. Her kuruluş farklıdır, bu nedenle bu tür bir deneyimde olması gerekenler için herkese uygun tek bir yanıt yoktur. Sonuç olarak, önceden paketlenmiş bir ürünün böyle bir kullanım için mevcut olan varsayılan bir yanıtı yoktur; bugün bu tür bir şeyi olduğu gibi kullanabileceğiniz bir çözüm yok.

Kendi sunucularınızda barındırılan özel olarak oluşturulmuş seçenekler için genel web portalı çerçeveleri yeni değildir ve geliştirme ekipleriniz, faydalanabileceğ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ı çalışmaları daha belirgin görüşlere sahiptir. Ö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.jsiçin yaptığı gibi kaynak ağacınızı önyüklemenize yardımcı olacak bir CLI içerir.

Portal araç seti olarak, çalışır duruma getirilmesi için emek gerektirir ve özelleştirme için TypeScript, Node.js ve React bilgisi gerekir. Bununla birlikte, bunun en güzel 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 kodu getirmenin iyi tanımlanmış bir yoludur.

İlgili içerik

• Microsoft Power Pages
• Backstage.io
• Yazılım mühendisliği sistemlerini uygulama