Selam Ekip - E45 - Application Delivery Platform

Selam ekip, ben Orda ve Master Data ekibinden Fırat.

Ben Storefront TRPDP ekibinden Cengiz.

Teknoloji ekiplerini tanıdığımız ve süreçler, teknolojiler gibi konuları konuştuğumuz Selam Ekip Podcast serisinin 45.

bölümündeyiz. 45. bu bölümde ADP ekibiyle birlikteyiz.

ADP, Application Delivery Platform ekibi.

ADP ekibini tanıyıp, ekip yapısını, kullanılan teknolojileri, pratikler gibi konulardan bahsedeceğiz.

Arkadaşlar hoş geldiniz. Hoş bulduk.

Hoş bulduk. Hoş geldiniz, hoş geldiniz.

Bugün dört tane... Misafirimiz var Application Delivery Platform bölümünden.

Arkadaşlar isterseniz ilk başta sizleri bir tanıyalım.

Kısaca herkes kendini tanıtabilir mi rica etsem?

Selamlar ben Mert. 2,5 senedir Trendyol'da çalışıyorum.

6 aydır da ADP takımındayım.

Topman'da da 6 senelik tecrübem var.

Toplu Erkan'a paslayayım ben de.

Teşekkürler Mert. Selam ben de Erkan.

Benim de 3,5 yıl oldu tren yolda.

2,5 yıl aşkım üstüne dediğinde Developer Experience alanında çalışıyorum bu takımda.

Benim de tecrübelerim bu şekilde. Ben de Eren'e bastım.

Selamlar ben de Eren.

Tren yolda 2,5 yıldır çalışıyorum.

Ve ADP takımında da birinci yılımı doldurmak üzereyim.

Onur. Selamlar, ben Onur.

Yaklaşık 6 aydır Trendyol'da çalışıyorum.

Application Program ekibindeyim.

Bundan önce de 5 yıldır DevOps Engineer olarak çalıştım.

Şu an Flipchart Program Engineer olarak Trendyol'da çalışmaktayım.

Süper, hoş geldiniz arkadaşlar.

Onur sen de hoş geldin 6 ay olarak.

Hoş bulduk. Hoş geldin.

DevOps idin? Şu anda burada DevOps musun yoksa rol değişikliği olarak mı geldin?

DevOps engineer olarak çalışıyorum.

Şu an platform engineer olarak çalışmaktayım.

Süper, süper. Çok güzel.

Hoş geldiniz efendim. Hoş geldiniz.

Teşekkürler. O zaman bir ilk sorudan başlayalım.

ADP takımı olarak, ADP takımı nedir, ne yapar, nelerden sorulur?

Bir kısaca, özet olarak bahsedebilir miyiz?

Tabii. ADP takımı ne yapardan başlayayım?

Biz temel olarak teknoloji hareketlerinin...

CICD süreçlerinden sorumluyuz.

Ekiplerdeki geliştiriciler yazdıkları kodu GitLab'e gönderdiği anda sorumlu olduğumuz süreçler başlıyor bizim.

CI adımlarında pipeline optimizasyonu, bunun haricinde son akübüle kod kalitesi raporları ve uygulamaların dependency'leri servettiğimiz Gradle GitLab Package Register gibi tool

var bununla. Bunların bakımını, stabilitesini koruyoruz.

CD süreçlerinde ekipler genel olarak Argo CD kullanıyor ama yaşadığımız Argo CD tabanlı stabilizasyon sorunları ve süreçleri standart hale getirmek istediğimiz için içeride geliştirdiğimiz Internal Developer

Platform tool'larını sunmaya başladık ve yaygınlaştırmaya devam ediyoruz.

Ürünün bazında sayarsak eğer GitLab ve GitLab Runner'lar Argo CD, Argo Workflows, SonarCube ve Gradle olarak başlıca sayabiliriz.

Harika. Yani aslında...

Oldukça geniş kapsamlı bir takım.

Oldukça sorumluluklar yüksek.

Ben şeyi merak ediyorum.

Ekibin ve Tribe'ın organizasyon yapısı nasıl?

Hani kendi yani bu ekipten ve Tribe'den biraz bahsedebilir misiniz?

Tabii ben bahsetmeye çalışayım.

Şöyle biliyorsunuz pek çok Tribe var.

Özelliklere göre ayrılmakta.

Bizim Tribe'miz Builder platform.

Builder platformumun aslında temel müşterileri içerideki developerlar.

Yani biz ürünlerimizi içerideki developerlara sunuyoruz.

Biz neye başlıyoruz peki? İçerideki pek çok standart...

Süper.

Harika yani aslında şey durumu birazcık tabii mesela benim açımdan, ben bir client ekibinde olduğum için benim açımdan biraz garip.

Hani buradaki sizin konsümerlerinizin yani aslında bir nevi müşterilerinizin yine developerlar olması, yine bize yönelik işlerde bulunmanız benim tarafımdan birazcık garip oluyor.

Ama yani oldukça güzel bir iş bence, oldukça güzel bir amaca hizmet ediyor.

Burada bir de şeyi sormak istiyorum.

Ekibin şu an tam olarak vizyonu nedir acaba?

Ben açıklayayım burada. tren yoldaki tüm teknoloji takımlarının servislerini en hızlı ve en kolay şekilde testten production ortamlarına kadar diplonlarını sağlamak.

Bunun yanında bu süreçlerde gerekli olan tool'ların stabilizasyonlarını en iyi seviyede tutmak diyebilirim.

Burada aslında şey de oluyor.

Ben hep böyle bu tarz böyle platform ekipleri hani ortak ekipler, developer ekipleri olunca direkt aklıma ilgi şey geliyor.

Diyorum ki trend yolu içerisinde bir ekipten bir ekipe sen komple hani biznesi farklı olan bir yere transfer yani rotasyon yapsan bile çoğu şey yine de ortak olacaktır.

Sanki bu işlerin böyle amacından biri de buymuş gibi hissediyorum hep.

Yani işte bu işin örneğin CICD kısmını şu anda yapıyorsunuz diye anlıyorum.

Çünkü işte biz GitHub'da örneğin bizim Fulfillment Tribe'ında bizim kendimize göre bir GitHub'da bir CICD yazmışız.

Bazı ortak yerleri alıp kendimiz üstüne ekliyoruz.

Ben komple başka taraftaki bir yere gitsem orada belki de çok farklı bir doküman ya da bir CICD dosyası yazmışlardır ve onu öğrenmem gerekiyordur.

Onu bana bir challenge olacak. Fakat hepimiz sizin...

ürünlerinizi kullandığımızda ortak CIC'lerle gideceği için çoğu şey standart olacak zaten Trendyol bazında.

O yüzden de benim için aslında o challenge'lar azalmış olacak gibi düşünüyorum.

Doğru mudur? Tabii. Tam olarak bahsettiğim gibi herhangi bir arkadaşımız herhangi bir ekipte kaldığı yerden devam edebiliyor bu süreçlere.

Değişiklik yapamıyor. Bunun yanında bu süreçleri standartize ettiğimiz için de gerekli adımları istediğimiz gibi yönetebiliyoruz.

Mesela pipeline'larda biliyorsunuz Jira entegrasyonu olan bir Cabımız var.

İşte task'in durumunu kontrol eden.

Geçen bir problem yaşamamıştı onunla ilgili.

Tüm ekiplerin problemini tek noktadan çözmüş bulunduk.

Süper. Peki burada sonuçta müşteri dışarıdaki bir müşteri değil.

Hani internal olarak bir developerlar ya müşteriniz.

Aslında bu da farklı bir tecrübe. Hani müşterinin developerlar olması.

Ya da şirkette şu an biz 2000 kişiyi sanırım teknoloji departmanı çok büyüdü.

Burada peki... 2022 en büyük zorluk ne oluyor bu tarz süreçte?

Takım içinde hem çok yaşadığımız zorluklar aslında gelen isteklerin çok diverse olması.

Hani bir request geliyor ama hani bunu nasıl apply edebiliriz konusu biraz daha böyle içeride ekstra çalışma gerektiriyor.

Onun dışında zaten... Biliyorsunuz Trendyol'da neredeyse 500'den fazla cluster, 10.000'den fazla da mikro servisimiz var.

Bunları dağıtması seamless bir şekilde özellikle bizi biraz zorluyor.

O yüzden yeni dönem projeleri olarak bunları nasıl iyileştiririz ve nasıl yeni feature'ları katarız ve bunları nasıl developerlar tarafından kullanılabilir hale getiririz, onlar üzerine çalışıyoruz.

Aynı zamanda bizim ürünlerimizi kullanan farklı...

Platform takımları da var.

Erkan'ın da bahsettiği gibi mesela Engineering Insights takımı özellikle GitLab'ı çok fazla kullanıyor.

Bu da GitLab üzerinde mesela çok fazla yük bindiriyor.

Bunları mesela nasıl scale ederiz ve kısımlarını daha çok tartışıyoruz.

Mümkün olduğunca aslında CNCF projelerini ya da kullandığımız Enterprise ürünleri nasıl trend yola...

adapte edebiliriz. Bunları nasıl yüksek loadda loadu kaldırabilecek şekilde yapabiliriz.

Bunlar genelde en büyük yaşadığımız challenge'lar oluyor.

Güzel challenge'lar ya.

Ben şahsen sevdim. Çünkü burada hani müşteriler developer teknik yani karşıdaki insanlar da çok teknik olduğu için çok farklı isteklerle dediğim gibi belki de geliyorlardır burada.

Bunda farklı challenge'lar oluyordur.

Peki burada mesela az önce bölümün başında konuştuğumuzda platform engineer mesela diye konuşmuştuk.

Örneğin DevOps'tan gelen biri var örneğin ekibe.

Bunun gibi platform engineer demek sonuçta hani business developer değil de farklı bir hani teknolojik bir ürün yazıp da aslında insanlara veriyoruz ya.

Burada platform engineer olarak mesela diyelim ki ben geçmek istiyorum.

Buraya mesela devam etmek isteyen ya da rotasyon yapmak isteyen insanlar tam olarak nelere odaklanmalı?

Şöyle abi ben 5 yılda Vox Engineer olarak çalıştım hali hazırda.

Şu anda tren yolunda yeni bir üyesiyim aslında.

Aynı zamanda da ADP'nin bir yeni bir üyesiyim ve platform tarafının biraz yeni üyesi olduğum için de benim bakış açım daha...

doğru olabilir belki. Burada DevOps engineer olarak çalıştığım için ben hem yazılım tarafında da hem de operasyon tarafında da bulunmuş biri olarak platform tarafına geçişim biraz aslında kolay oldu.

Burada platform engineer'ın genel olarak uğraştığı şeyler self-service sistemler oluşturmak, developer'lara kendi süreçlerini kendileri yönetebileceği otomasyon süreçleri sunmak gibi senaryolar olduğu için aslında burada

biraz da altyapıya da hakim.

Geliştireceği platformun self-service uygulanmasının için platform Onun da biraz olsun fikir sahibi olması gerekiyor ki onun geliştirmesini kolayca yapabilmesi gerekiyor.

Aynı zamanda yazılımla uğraşma, geliştirme yapacağı için de aslında yazılım standartlarına ve yazılım hakkında da bilgi sahibi olması gerekiyor.

En azından burada iki tarafı da sanki DevOps Engineer gibi, iki tarafı da bilgi sahibi, know-how'ı gerekli gibi bir söz konusu.

En azından altyapıda da biraz fikir sahibi olması, altyapıdan custom tool'lar olur, güvenlitesi olur veyahut CI-CD süreçleri olur.

Çünkü burada bir otomizasyondan bahsediyoruz.

Self-service bir sistemden bahsediyoruz.

Bu süreçleri en azından biraz bilmesi, onun geçecek arkadaşın daha rahat oryante olması anlamına geliyor.

Halihazırda zaten self-service geliştirme yapacağı için de aynı zamanda yazılım geliştirmeyi seviyor olması ve bu konuda öğrenmeye açık olması.

onun için iyi olacaktır.

Süper abi harika tavsiyeler.

Yani aslında içeride çok böyle diverse bir sistem olduğu için yani insanlar işte çeşitli rotasyonlar yapıyorlar ve etrafımda da var farklı alanlara ilgi duyup bu alanlarda kariyerini

devam ettirmek isteyen insanlar için oldukça güzel tavsiyeler oldu.

Birazcık böyle bir azıcık daha soft bir taraftan bir soru sormak istiyorum.

Anlatacak olsanız, söyleyecek olsanız ekipteki bir üyenin, ekipteki bir kişinin bir günü nasıl geçiyor aşağı yukarı sizce?

Benim bir günüm aslında şöyle geçiyor.

Bir gün öncesinin support requestlerinden kalanlar var mı yok mu bunları bir inceliyorum.

İnceledikten sonra hangilerinin yapılabilip yapılmayacağını gözümle tartıp...

Aslında güne başlıyorum.

Daha çok her günlük toplantılarımız oluyor daily olarak ve onun dışında birkaç tane daha standart meetingimiz var.

Onun dışında takvimimiz genelde boş oluyor.

Daha çok kendi tasklarımıza odaklanabiliyoruz.

Eğer on-call'daysak zaten çoğunlukla support tasklarına bakıyoruz ya da geriye dönük eksik bir dokumentasyon.

Ya da bir technical debt varsa onlara bakıyoruz.

Onun dışında da feature geliştirmeye yönelik çalışmalara gün boyunca devam ettiriyoruz.

Bu arada support konusunda da...

Biz Pandora ve SFX'in ortak çıkarttığı QA platformunu kullanıyoruz.

Tabii bunun altında birden fazla subtopiklerimiz var.

Gitlab, Sonar, Kube, Gradle, TBP, Argo CD gibi.

Genelde kullanıcılarımız da developerlar olduğu için developerlardan gelen bu ticket'ları cevaplıyoruz.

Ve aynı zamanda platform engineer olduğumuz için sahibi olduğumuz ürünlerin de herhangi bir incident ya da availability problemi olduğunda Aynı zamanda onlara müdahale ediyoruz.

Aslında genel olarak gün böyle geçiyor.

Biraz takvim açısından rahat olsak da aslında gün içinde tatlı bir tempo oluyor.

Süper abi teşekkürler.

Geldiğin gibi en başta bir zaten diyordun ya mesela gözüme tartıp en başta bir şeye bakıyorum.

Hem bir supportta neler var vesaire.

Çünkü burada hani şirket içerisinde bir destek verdiğiniz bir kısım var bir ürün var diye anlıyorum.

Peki burada haftalık olarak örneğin burada bir haftalık iki haftalık sprintler yapanlar vesaire oluyor ekipler olarak.

Biz de örneğin bir haftalık sprint yapıyoruz.

Burada örneğin sizler. Nasıl pratikler uyguluyorsunuz?

Çünkü bir support kısmı demiştin.

Dokümentasyon kısmı var. Çünkü birçok kişiye self-service hizmet veriyorsunuz vs.

Burada sizler hangi pratiklerle ilerliyorsunuz ekipte?

Şöyle abi, biz de sprint koşuyoruz aslında.

Bizim de içeride kendi geliştirdiğimiz self-service uygulamamız var.

İsmi Trendweaver Builder Platform.

Buradaki geliştirmeleri aslında sprint koşuyoruz.

Bir de bizim günlük işlerimiz olan Eren'in de bahsetmiş olduğu support...

yani destek taleplerine bakıyoruz.

Aynı zamanda da ilgili olan yani bizim ilgilendiğimiz ürünlerin availability'siyle ilgileniyoruz yanlış olarak.

Bizim içeride mindsetlerimiz çok farklı.

Yani şöyle farklı alanlardan geliyoruz.

Developer mindseti olan arkadaşlarımız da var.

Infrastructure mindseti olan arkadaşlarımız da var.

Kimin neye yatkın olduysa o noktadan destek birbirimizin bilgi aktarımı ile beraber destek veriyoruz.

Siz de sprint koşuyorsunuz, biz de sprint koşuyoruz.

Sadece bizim sprintimiz genellikle bu platform uygulamasıyla kısıtlı.

Ekstra araya tabii ki de backlogdan, teknik borçlardan da işler alıyoruz.

Ürünlerle alakalı şu an aktif olarak uğraştığımız GitLab var.

GitLab'i ölçeklendirmesini şu anda arttırmaya çalışıyoruz orada.

Bununla tabii sprint dahil ediyoruz.

Onun haricinde haftalık operasyon review ettiğimiz toplantımızda warm diyoruz.

Biz buna bu support gelen destek taleplerini inceliyoruz burada bir takımca hep beraber.

Çünkü çok fazla ürünümüz var ve ürünlerden çok fazla talep geliyor.

Bunları analiz etmemiz gerekiyor ki bize aslında işleri yapmamız gereken işleri önceliklendirelim ona göre.

Önceliklendirelim hangi destek çok sık geliyorsa.

onu önceliklendirip onu çözmeye çalışıyoruz.

Hafta olarak da bunu warm toplantılığında yapıyoruz ve aksiyonlar alıyoruz.

Burada gerekiyorsa da bu aksiyonları aslında backlog'a da task'ını açıp önümüzdeki speed'i de çözüyoruz aslında.

Onun haricinde launch and learn dediğimiz genel olarak triangle'ın içerisine hakim olan session'lar düzenliyoruz ki çünkü Eren'in de bahsetmiş olduğu on call sadece

o gün destek taliplerine bakıyor.

Diğer arkadaşlarımız geliştirmelerine veya ilgili olduğu taslarla ilgileniyor.

Birbirimizi kesmemek adına ya da geliştirme sürecini aksatmamak adına böyle bir karar aldık.

Bu launch and learn session'larında aslında biz o on call'daki arkadaşın öğrendiği know-how'ları birbirimize aktarıyoruz veya yeni teknolojiler deniyoruz ekibimiz için, yeni

araçlar deniyoruz.

Bunları içeriye nasıl entegre ederiz, onları tartışıyoruz, birbirimize paylaşıyoruz know-how'larımızı.

Genel olarak da bu süreçleri doküment etmeyi çok seviyoruz ki ileride oluşabilecek aynı sorunlarda veya problemlerde geçmişte...

kazandığımız tecrübelerle bunların üstesinden kolayca gelebilmeyi sağlamak adına bunları dokümante etkileyip bunları nasıl diyoruz gerekirse ve arkadaşlarımızla paylaşıyoruz.

Genel olarak böyle söyleyebilirim.

Çok güzel pratikler.

Yani her takımda bunları benzer şekilde görmek oldukça keyif verici, oldukça güzel.

Takım kültürünü de direkt olarak gösteren şeyler olduğunu düşünüyorum ben burada.

Biraz daha şu taraftan bir yaklaşmak, bir soru sormak istiyorum.

Şimdi pek çok ürününüz var, pek çok ürün yönetiyorsunuz.

Dolayısıyla her takım yaşıyordur bunu.

Herhangi bir durumda problemler çıkıyor, problemler yaşanabiliyor.

Ürünlerde herhangi bir sorun, herhangi bir problem yaşadığınız zaman aksiyon alma şekliniz nasıl oluyor?

Nasıl aksiyon alıyorsunuz? Ve ne gibi burada problemlerle karşılaşıyorsunuz?

İyi satın, hikayeler önemli.

Aynen abi incident. Bizim için şey aslında blameless culture'ı mümkün olduğunca sahiplenmek istediğimiz için incident biraz böyle insanın gözünü

korkutuyor başta. Ama aslında çok da güzel süreçler bana kalırsa en çok incident'ı açan benim galiba.

Bir de özellikle yani core komponentler bizde olduğu için teknoloji ekiplerinin sürekli dokunduğu.

Bir yavaşlık olduğu zaman zaten arkadaşlar da hemen yazıyor, hemen git lafa yavaşladı mı ya da Argo CD'de bak böyle bir sıkıntı var falan gibi.

Tabii onlara gelmeden önce biz de kendi tarafımızda proaktif bir şekilde aksiyonlarımızı aldık servislere dair.

Aslında biraz önce bahsettiğimiz Developer Productivity Engineering altındaki bir holder takımının altyapısını kullanıyoruz.

Burada bir metrikler bizim için çok önemli oluyor.

Bu şekilde servislerin availability'lerini, SLO'larını tanımladık.

Herhangi bir anomali durumunda önceden bize alertler geliyor.

Aynı zamanda on-call uygulamasından da Aziz o günün on-call'ına aslında ekstra bildirimler de geliyor.

Tabii ki burada bir incident yaşandığı zaman genel olarak hızlıca aksiyon olup bottleneck nerede oluşuyor ya da hangi komponentin alt bileşeninde bir sıkıntı var hemen onları loglardan, metriklerden

bulup nasıl düzeltebiliriz buna yönelik çalışmalar yapıyoruz.

Bu süreçler tamamlandıktan sonra da yani servis eski haline döndüğü zaman da bu konuyla alakalı postmortemimizi yazıp bunları da aslında tribe içinde paylaşıyoruz.

Ki en azından know-how'ı bütün takımlar arasında dağıtalım.

Herhangi bir problemle karşılaşıldığında da geriye dönük bizim için de dokumentasyon olmuş oluyor.

Onun dışında biz bu incidentları yaşadığımız zaman Onur'un da bahsettiği gibi warm toplantılarında bu postmortemin üzerinden geçip nasıl bunları düzeltebiliriz ya da nerelerde

sıkıntılar varsa oralara nasıl çözüm buluruz.

Aynı zamanda bunları da warm meetinglerinde bunları bu incidentların üzerinden geçip nasıl...

düzeltebileceğimizi konuşuyoruz.

Aynı zamanda tabii ki burada high availability gibi konularda önemli olduğu için bunları nasıl failover yapabiliriz, aradaki failover sistemlerini nasıl otomatize ederiz gibi konforanlarımızı da

aslında iyileştirmeye yönelik çalışmalar yapıyoruz.

Okeydir. Burada dediğin gibi yani çok fazla sorunlarda işte örneğin temel yerdesiniz.

Bir sorun geldiğinde önceden aksiyon alma kısmıdır vs.

Bunlara gerçekten de dikkat etmek gerekiyor ki sizin gibi böyle temel ekiplerde eminim Daha da kritiktir bu tarz konular.

Peki burada böyle kritik yerler yapılırken hangi teknolojileri kullanıyorsunuz?

Yani bu ürünleri yazarken kullandığınız birden fazla dil mi var?

Örneğin dil olarak, teknoloji olarak nelerle uğraşıyorsunuz burada?

Tabii biz birçok ürüne baktığımız için kullandığımız teknolojilerde çok fazla.

Çünkü platform ekibinin eli birçok.

alana dokunuyor. Hem yazılım geliştirme tarafında hem de o süreçler hakkında.

Bundan dolayı biz yazılım geliştirme tarafında genel olarak Go dilini, Node.js dilini ve React.js kullanıyoruz.

Tabii ki de burada biz unit test yazıyoruz içeride.

Gerekli bağımlılıkları da kullanıyoruz.

Burada birden fazla dil ve framework da elimiz dokunuyor.

Database tarafında kullandığımız genel olarak Postgre var.

Postgre ile beraber Elasticsearch ve Couchbase de kullanıyoruz.

İkisini entegre... Elastik, sosyal kağıtçı, N8'i kullandığımız alanlarda oluyor.

Self-Service uygulamayı geliştirdiğimiz için de genellikle bizim işimiz çoğunlukla araçlarla haşır neşir oluyor.

İşte Kubernetes'dir, Docker'dır.

Bununla birlikte daha önceden de bahsettiğimiz gibi içeride Self-Service bir sistem geliştiriyoruz.

Onun için adında Trendyol Builder Platform olduğunu söylemiştim.

Burada da Trendyol Builder Platformu aslında Open Application modeli baz alarak bir Self-Service sistem sunuyor.

Open Application Model bir standartizasyon aslında.

Bu modeli de kullanan bir tane kübüvele dediğimiz aracımız var.

Biz aslında tren yolu bildir platformunu kübüvele üzerine geliştirmesini gerçekleştiriyoruz.

CI tarafında...

GitLab CI'yi çok aktif olarak kullanıyoruz entegrasyon tarafında.

İçeriği de çok aşırı şekilde yaygınlaştırmış durumdayız GitLab'e.

Bundan dolayı da aslında GitLab'de yavaşlıklar vs.

yaşadığımız için de burada GitLab üzerinde geliştirmeleri devam ediyoruz.

Oradaki ölçeklendirme süreçleri vs.

devam ediyor. Trendle'un aslında %70'i Continuous Diplomacy için Argo CD'yi kullanıyor.

Ama burada Argo CD'de yaşadığımız sorunlardan kaynaklı.

Biz içeride kendi sert servis sistemimizi yazıyoruz.

Trendle Builder Platform dediğimiz.

Ama aktif olarak da hala... 170 Argo CD'yi kullanmaya devam ediyor.

Kron cap'lar yani gerekli schedule ettiğimiz cap'lar için Kubernetes'in kendi kron cap'ını kullanmıyoruz.

Oyun alanımız çok dar orada, güvenites kroncaplarında.

Orada Argo Workflow'un kroncaplarını kullanıyoruz.

Ve bu şekilde aslında mesela örnek olarak güveniteste timezone ayarı vesaire de yoktu.

Argo Workflow da bunları seyredetti.

Bizim oyun alanımızı genişletmek istediğimizden dolayı tercihimiz Argo Workflow'dan oldu.

Yeni GitLab kurulumuna başladık.

Ölçeklendirmelerle alakalı problemlerimiz vardı.

Yüksek trafik alıyorduk. Ondan dolayı da yeni GitLab kurulumunun aslında sunucu provisionunu...

Teleformla yapıyoruz. Config Management'ın üstüne Ansible'da yapıyoruz.

Aktif olarak kullanıyoruz ikisini de çok yaygın bir şekilde.

Genel olarak bu genel yüzeysel olarak bu teknolojileri kullanıyoruz.

Tabii ki de bunların getirdiği bağımlılıkları olan teknolojiler de var.

Ama böyle bu yüzeysel olarak söylemiş oldum bunları.

Abi şimdi bu kadar böyle aslında karmaşık kompleks bir sistemi yönetmesi ve işte sürdürmesi de ayrı bir problemdir diye düşünüyorum.

Yani hani... kurması vesaire neyse hani o taraflar belki halledilebilir ama maintain etmesi, ilerletmesi falan biraz problemli olabilir diye düşünüyorum.

Peki siz burada stabiliteyi iyileştirmek ve önemini daha yükseltmek için ne gibi pratikler uyguluyorsunuz?

Genel olarak hali hazırda zaten haftamızın yarısı bu ürünlere destek vermekle geçiyor.

Bir ürünlerin stabil olmasını sağlamakla geçiyor.

Burada başlıca destek talepleriyle ilgileniyoruz hali hazırda.

Eren'in de bahsetmiş olduğu uygulamaları proaktif bir şekilde izliyoruz.

Ölemler kurup izliyoruz.

Biz T anında, sorun anında çok kısa bir sürede haberimiz oluyor.

Bununla birlikte bu stabiliteyi sağlayabilmemiz için de bir sorun anında biz CICD süreçlerini bloklayan bir yapıda kuruyoruz.

Yani ambarga koyuyoruz bir noktada ki sorun anında diplomat kimse çıkmasın veya üstüne geliştirme yapmasınlar ki sorun...

Daha da karmaşık hale gelmesin.

Genel olarak bu şekilde feedback'leri çok önem veriyoruz müşterilerden.

Bizim müşterimiz developer olduğu için onların mindset'inde olacağı için aslında onların mindset'i bizim de mindset'imizde aynı noktada buluşuyoruz.

Onların feedback'i bu noktada bizim için çok önemli.

Onların feedback'lerini dinleyerek yaşadıkları sorunları bizim uygulamalar üzerinde yaşadıkları sorunları en çok tekrarlayanları otomatikleştirmeye çalışıyoruz.

En başta dediğim gibi aslında ekibi platform engineer bir self-service sistem sağlamak ve o süreçleri otomatikleştirmek bir noktada.

Fazla fazla tekrarlayan problemleri nasıl otomatikleştiririz, nasıl self-service şekilde çözeriz bu noktalarda düşünüyoruz.

Stabil olmayan yerlere de bu mantığıyla yaklaşıp stabilleştirmeye çalışıyoruz aslında.

Süper abi. Problemlerden bahsettik.

Problemleri hani işte bug tracking'dir işte herhangi bir sorun yaşandığı zaman monitoring'in önemi de oldukça artıyor aslında.

Burada ürünlerinizi yaptığınız işleri nasıl monitör ediyorsunuz?

Yani hangi metriklere bakılıyor ve bu metriklerden herhangi bir aksiyon maddeleri çıkıyor mu?

Bundan Eren ufak bahsetmişti ben de tekrar üstünden geçeyim.

aktif olarak bir yoldur.

Yani ekibimizin sağladığı Prometheus veya Graphene altyapısını kullanıyoruz.

Kendi ürünlerimiz için tanımladığımız dashboardlar veya alertlarımız mevcut.

Buna bağlı olarak bu ürünlerin başka ekiplerle bağıntısı olan yerleri de monitör etmeye çalışıyoruz.

Yanında ekiplerle gerekli iletişimleri kurarak, metrikleri birleştirerek.

Yanında Critical Alertlarımız için Trendyol içerisinde kullandığımız on-call servisimiz var.

Critical Alertlarımız bu servise bağlı olarak çalışıyor.

Select'ten ve telefondan bildirim atıyor.

Bunun haricinde hali hazırda visual edemediğimiz önemli metrikler varsa bunları export edip observe edebilmek için geliştirmeler yapıyoruz ek olarak.

Örneğin Argosiz'de yaşadığımız latency problemleri vardı.

Bunları tespit edebilmek için ek geliştirmeler yaparak metrikleri export ettik.

Böylece lead time'ımızı korumaya çalıştık.

Bu tarz lead time'ı artırmak için olan birden fazla metrikler yaşandığı gerekiyor.

Sizde de bayağı var gibi. Peki burada aslında birden fazla...

Tool'unuz var, ürünleriniz var ve bu ürünlere destek veriyorsunuz diye anladım.

Peki ileride daha da bu ürün sayısı artabilir mi?

Yeni ürün projelere gelecek mi?

Şu an aslında bağlı olduğumuz Argo CD'den kurtulmaya çalışıyoruz diyebiliriz.

İçeride kendi geliştirdiğimiz, Onur'un bahsettiği tool'umuzla birlikte.

Yeni bir tool...

olursa yani destek vermemiz gereken bir tool olursa onun için de gerekli metrik tanımlarını yaparız yani.

Şimdi ilaveten bizim etki edebileceğimiz noktalar hani CI, CD ya bu durumda ekiplere sağlayabileceğimiz en güzel şeylerden birisi onların CI, CD süreçlerinin hızlı, sorunsuz olması.

Hızlı olması konusu aslında biraz karmaşık ama bu da hedeflerimizden birisi.

Bunu nasıl çözebiliriz?

Bildiğiniz gibi siz de söylemiştiniz.

Ekipler kendi CI pipeline'larını yapıyorlar.

Kendi sorunlarını kendilerini çözüyorlar şu an.

Aktif olarak CI pipeline...

Desteğimiz çok yok. Sadece bize Pandora Q üzerinden soruz olduğunda know-how'umuz dahilinde cevap vermeye çalışıyoruz, destek olmaya çalışıyoruz.

Ama onun dışında GitLab CI biliyorsunuz açık bir tool, dökümanı falan bize ait değil.

Bayağı güzel bir döküman da var ama sonuçta farklı bir tool, third party.

Bizim buradaki hedefimiz ne?

Sorunlar her ekipte ayrı ayrı çözülmekte şu anda.

Ayrı ayrı vakit harcamakta.

O learning curve'ı her developer ayrı ayrı aşmakta şu anda.

Yani bizim hedefimiz CI konusunda...

ekiplerin kullandığı, en çok kullandığı şeyleri en azından template olarak sunarak onların bu tür şeyleri tekrar tekrar çözmeye çalışmaması.

Sonuçta hepimiz tekerleği baştan inceltmek istemiyoruz ya.

Örnek veriyorum sadece. Çok daha fazlası olur tabii ki de.

Atıyorum test, build gibi şeyler çoğu yerde vardır ya.

Bunlar ekipler ayrı ayrı çözmek zorunda değil.

Tabii isterlerse yapabilirler. Ama bizim burada bazı template'ler sunuyor olmamız onların bu lead time'ını aslında kısacaktır değil mi?

Çünkü daha hızlı bir ürün çıkacaklar.

Belki o pipeline'ler daha hızlı çalışacak gibi şeyler olacak.

CD konusunda da zaten Argo CD kullanılıyor çoğunlukla %77 civarında.

Ama öte yandan %6-7 arası bir TBP kullanımı var.

TBP biliyorsunuz bir Internal Developer Platform.

Tabii biz takım olarak onun Application kısmındayız.

Yani biz Application Delivery'den sorumluyuz TBP'de.

Biz TBP'de hani mevcut çözümlere kıyasla mesela Argo CD'ye kıyasla çok daha hızlı bir...

Continuous Delivery Experience sunuyoruz aslında.

Bu da baktığınızda lead time'ı düşürür değil mi?

Sonuçta uygulamanızı daha kısa sürede tipte etmiş oluyorsunuz.

Ve bunun ötesinde TBP yani Trendyol Builders Platform pek çok farklı özelliği beraberinde getiriyor.

Bir platform olduğu için self-service'i aktifleştiriyor developerlar için.

Yani bu ne demek? Geliştiriciler şu anda veri tabanı veya başka...

altyapıyla iletişim kurarak manuel yürüttüğü şeyleri şu an servis olarak yapabilmekteler.

Application kısmına gelirsek, application kısmına da biz aslında onların ihtiyaç duyduğu her şeyi eklemeye çalışıyoruz.

Yani bir uygulamayı kurdun, tamam güzel çalışıyor.

Ama neye ihtiyacın olur sonrasında?

O uygulamaya monitör etme ihtiyacın olabilir, loglarına bakma ihtiyacın olabilir ya da scale etme ihtiyacın olabilir.

Pek çok şey geliyor aslında. Biz bu konularda...

TBP'ye yeni featureler eklemeye çalışıyoruz.

All the rules sayfamız var örnek olarak.

En çok ihtiyaç duyulan metrileri oraya koyduğumuz, visualize ettiğimiz bir sayfamız.

Onun dışında configuration, secret management gibi şeyleri de yine TBP'ye uygulamaların sayfalarına beraberinde getiriyoruz.

Buna ek olarak TBP bizim oluşturduğumuz standart bir deployment template'ını kullandığı için aynı bunun CI template'ı gibi düşünün.

Kullanıyorsunuz, değiştirmeniz gereken yerleri değiştiriyorsunuz, eziyorsunuz.

Bizim de bu template'larımızı kullandığı için daha stabil, Daha performanslı bir servis ortaya çıkıyor.

Nedir mesela? Istiyor kullanıyoruz hepimiz içeride biliyorsunuz.

Mesela istiyor için zero downtime yapmak istiyorsanız geçmeniz gereken bir config var.

Ve bunu pek çok kişi hala hazırda geçmiyor.

İnsanların bilmesi gerekiyor.

Mesela bu otomatik geliyor. Bunun yanı sıra progressive delivery'e değinecek olursak yine TPP'de bizim tam tutumuz sayesinde ekipler çok kolay bir şekilde canner ve büyük blue green kullanabilmekle beraber zaten by default canner olarak deploy oluyor.

Bunun gibi şeyleri ekipler çok kolay bir şekilde bizim dokümanlarımızdan bakıp kullanabiliyorlar.

uygulamalarını daha kolay bir şekilde eksendirebiliyorlar.

Bütün o Kubernetes'i, Argo Rollout'u öğrenmek yerine sadece onlara sunulan, onların ihtiyaç duyulduğu kısımları öğrenmeye çalışıyorlar.

Buradaki geliştirmeler de onlardan feedback alınarak yapıldığı için aslında tam olarak onların istediği şeyi yapmış oluyoruz.

Yani onların tam olarak ihtiyaç duyduğu şeyleri onlara sunuyoruz, developerlara diyebilirim.

Burada da evet yani mesela developerlar olarak yani gerçekten şey güzel oluyor.

Ben sadece developer işine odaklanıyorum.

Development kısmına bu işin örneğin ben business ile ilgili bir development yapacaksam benim derdim genelde daha çok Çok oraya odaklanmak oluyor bu tavsiyeler sayesinde.

Böyle bir yararı oluyor. O yüzden zaten tavsiye ederiz herhalde herkesten bu ürünlerin kullanmasını.

Burada peki iş dışında tam olarak ekip anlamında birlikte yaptığınız böyle aktiviteler vs.

var mıdır örneğin? Eski bölümlere baktığımızı belki görmüşsünüzdür.

Yemek üzerine olan gurme ekiplerimiz var.

Şuraya gideriz, buraya gideriz. Şu yemeği yeriz diyenler vs.

oluyor. Mangal yapanlar oluyor. Farklı aktiviteler olan oyunlar oynayan oluyor gibi böyle.

Çünkü bazı ekipler farklı farklı şehirlere dağılmış oluyor.

Bazıları aynı ekipte oluyor. O yüzden her ekibin böyle dinamiği farklı oluyor.

Sizlerde böyle yaptığınız şeyler var mı?

Abi bizde de her şey var.

Yani yemek konusunda özellikle çok başarılıyız bence.

Kendimize güveniyoruz diyorsun. Aynen yani 6 kişiyiz biliyorsunuz.

3 arkadaşımız Ankara, İzmir ve Diyarbakır'da.

Mert Diyarbakır'da ve çok deneyimli bir kebap tadımcısı mı diyelim?

Gurmesi, kebap gurmesi.

Kebap gurmesi aynen.

Ankara'da da çok iyi bir yer var.

Eren söylemişti ama henüz gidemedik.

Biz takımca...

Böyle farklı şeylere gidebiliyoruz aslında.

Mesela geçenlerde İzmir'e gittik.

Onur İzmir'de ve İzmir'de çok iyi bildiği bir yere götürdü bizi.

Yemek yedik, balık yedik.

Gayet keyifliydi.

Ardından İzmir'i gezdik.

Bunun dışında İstanbul'da 3 kişi var.

Ve Developer Productivity Engineering grubundan aslında bütün takımlarda ofise gelenler oluyor.

Yani haftada...

Bir iki gün geliyor genelde insanlar.

Ve ofiste görüşüyoruz.

Ofiste görüştüğümüzde ne yapıyoruz?

Hani beraber spora gidenler var.

Ben de onlardan biriyim. Bunun dışında spordan sonra yemeğe gidenler var.

Yemekten sonra hatta farklı bir aktivite olarak ice skating'e gidenler var abi.

Ofis dışında kamp da yapıyoruz aslında.

Mesela yılda bir... Bunu ilk defa duydum.

Aynen yaptık aslında. İki ya da üç kere yaptık hatırlıyorum.

Ekipçe yani sadece App Delivery platformuna kısıtlık almayarak yine Productive Engineering grubuyla kamp yaptığımız oldu.

Bu kampı genelde bir gece tuttuk aynen.

Kamp dışında da bazen daha uzak bir yer seçiyoruz yemek yemek için ofisten sonra.

O da pek çok kişi biliyordur bizim takımdan zaten Baranet diye bir yer.

Aslında bizim takımdan da herkes gitti sanırım oraya.

Favori mekanımız da orası.

Reklam olmuyor ama. Olsun.

Kebapçı mıydı? Evet abi kebapçı tavsiye ederiz.

Evet buradan kebap bilgimizi de paylaşmış olduk.

Kebap konusunda belli ki ekip tecrübe sahibi.

Arkadaşlar çok teşekkür ederiz.

Çok keyifli bir sohbet oldu. Buradan da böylece Application Delivery Platform ekibini de tanımış olduk.

Teşekkür ederiz. Teşekkür ederiz.

O zaman bir sonraki bölümde görüşmek üzere.

Bye bye. Görüşmek üzere.