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ş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, aşağıda açıklanan modelin bazı öğeleri için farklı terimler kullanabilir, ancak model yine de yönlendirmenize 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, yorucu olan veya karmaşıklık veya izinler nedeniyle geliştiricinin kendi başına gerçekleştiremeyenlerdir. Bu son parça, el ile hizmet masası işlemiyle 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 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 denemeyi etkinleştirmek 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.

Bununla birlikte, 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ın denetlenmesi, idaresi ve azaltılması için de önemlidir (örneğin, kullanılmayan ortamlar).

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 tam otomatik bir akışa geçiş yaptığınız Power Automate gibi bir işlemle el ile 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şturun ve ihtiyaç ortaya çıktıktan 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	Veri Akışı Açıklaması
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üzenleyici	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 ve/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'sini gruplandırmak ve erişmek için kavramsal bir 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 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 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 gelebilir. 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ü derlemem 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üne alındığında, API'ye işlevsellik kazandırmak için genişletilebilir bir sağlayıcı modelini izleyen sistemler oluşturun veya tanımlayın. 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, 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 zorluklar nedeniyle çekişme 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 "takmasına" izin vererek bu gerginliği ortadan kaldırmayı sağlar. 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ı

Varlıklar

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 bilgileri
• 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, 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ı
• Veri Akışı 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 baştan oluşturmak, 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:

• Ortamlar
• Kaynaklar
• API'ler
• Depolar
• Bileşenler
• 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ı 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 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 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ş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ışı)
• 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.

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 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. Bir sistem aracılığıyla bu şablonların kullanımını merkezileştirmek, geliştirici self servisini etkinleştirir ve kuruluş standartlarına veya ilkelerine uyumluluğu zorunlu kılmaya yardımcı olan korumalar oluşturur. Geliştirici platformu düzenleyiciyi 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ı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ımlarda ve ortamlarda otomatik olarak beslemek 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 eylemler, GitHub Actions veya Azure Pipelines kadar uygun bir öğeyi döndürmenin gerekli olmadığı veya ölçeklendirme için uygun maliyetli olmadığı 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ştirebilir.
• (İ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/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 yapmak için genel bir iş akışı veya görev yürütme altyapısı 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ş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ğıtım 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 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 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 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ı, 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 çıkaracak şekilde ayarlayabilirsiniz.

CI/CD sistemi kullanmanın en iyi özelliği, genellikle rastgele CLI'leri çalıştırmayı destekleyecek şekilde ayarlanmış olmaları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

Şablonları işleyebilen diğer geliştirici platformu sağlayıcılarının bazı örnekleri aşağıda 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şlemi 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, 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 öğeleri içerebilir. 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 çekme isteği oluşturma ister geliştirici olmayan kişilerin Power Platform gibi bir şey kullanarak yanıt vermeleri için el ile iş akışı adımları oluşturma, aynı şablon tabanlı model bir 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 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.

Ö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 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 SCIM gibi protokollerin kimlik sağlayıcısı gruplarına (AD grupları gibi) bağlanma desteğinden de yararlanmaya 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 rol tabanlı erişim denetimi (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 insan olarak tanımlıyoruz. 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ş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 Geliştirme Merkezi 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 grubun veya kullanıcının (SSO ile bile) kendi temsiline 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 (örnek: 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 aşağı akış sistemlerini güncelleştirebilir ve bunu yapmak için kullandığı ekip için ilgili tanımlayıcı ilişkilerini kalıcı hale gelebilir.

Ö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ı yararlı olabilir. Örneğin GitHub'ı göz önünde bulundurun:

Her sistem için, kullanıcı belirteci olmayan bir API aracılığıyla bir kullanıcı kimliği başka bir sistemi arayabilirseniz, 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 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:

• 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.
• 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 geçirir. geçirilen URI bir nonce / tek seferlik kullanım kodu içerir.
• 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ı her türlü varlık gereksinimini 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, DataDog veya SonarQube gibi ürünlerdeki 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 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, Vakfınızın 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 düşünülebilir ve anlaşılı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, 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, 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ı 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 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 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 ç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 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 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/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 içermeyen ü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 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 ç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ği olduğu göz önüne alındığında, bu, geliştiricilerin ve ilgili işlem 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, bugün böyle bir şey için olduğu gibi kullanabileceğiniz önceden paketlenmiş bir ürün için herhangi 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 dokunabileceğ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 fazla fikirle karşılanı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 gerektirir ve özelleştirme için TypeScript, Node.js ve React bilgileri 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 1^st ve 3^rd taraf kodunu getirmenin iyi tanımlanmış bir yoluna sahiptir.

İlgili içerik

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