- Startup ortamında DevOps, staff engineering ve platform engineering kavramlarının etkili biçimde uygulandığı örneklerin paylaşımı
- Konuşmacı Chad McElligott, Shopify tabanlı abonelik ve sadakat hizmetleri sunan Smartrr'da kıdemli staff engineer
- Startup’ların kendine özgü kültürüne ve gereksinimlerine uyarlanmış mühendislik metodolojileri önerisi
[Temel kavramlar]
DevOps
- DevOps’un tanımı kişiden kişiye değişir; kimi için bir unvan, kimi içinse bir çalışma biçimidir
No Ops olarak DevOps kavramı, yazılım mühendislerinin Ops ile ilgili tüm işleri kendilerinin üstlenmesine yol açar- DevOps, iş birliği odaklı bir yaklaşım, tekrarlayan ve manuel işlerin ( toil ) otomasyonu ve modern araçların kullanımıyla müşteriye hızlı değer sunmaktır
- Sadece bulut kullanımı, altyapının kod olarak tanımlanması, CI/CD pipeline’ları kurulması gibi teknik unsurlar değil; iletişim ve iş birliği engellerini kaldırarak daha iyi sonuçlara ulaşmak da özüdür
Platform Engineering
- Platform Engineering, geliştiricinin bilişsel yükünü azaltmaya yönelik teknik bir yaklaşımdır
- Amaç, ürün geliştirme hızını ve sistem güvenilirliğini aynı anda artırmak; bunun için geliştiricilerin çalışmalarını destekleyen temel bileşenleri sağlamaktır
- Verimliliği artırmak ve geliştirici deneyimini iyileştirmek için platform engineering ekipleri kuran büyük şirketlerin sayısı artıyor
- Manuel Pais ve Matthew Skelton’ın Team Topologies kitabıyla yaygınlaştı; mühendislik yetkinliğini güçlendiren örnekler çeşitli mecralarda görülebilir
Staff Engineering
- Staff Engineering, belirli bir zihniyet ya da teknik değil, kurum içinde yazılım mühendisinin üstlendiği bir roldür
- Senior Software Engineer sonrasındaki kariyer aşamasıdır ve yazılım mühendisliğinde hizmetkâr liderlik olarak da açıklanabilir
- Staff+ mühendisler yalnızca bireysel işlerle ilgilenmez, sorumluluklarını organizasyonun geneline genişletir; yöneticiler veya VP’lerle birlikte çalışarak somut uygulama ve bakış açısı sunar
- Will Larson’ın Staff Engineer kitabı, Staff rolünü dört arketipe ayırarak açıklar: Architect, Right Hand, Tech Lead, Fixer
[Startup kültürü]
- Girişim sermayesiyle desteklenen startup’larda büyüme uğruna harcamaların geliri aşması sık görülür
- Yatırımdan sağlanan sermaye bir
runway olarak kullanılır; amaç, bu runway tükenmeden önce büyüme ve kârlılığa ulaşmaktır
- Bu ortam iki temel kültürel özellik yaratır
- Boşa harcanacak zaman yoktur
- Startup’ta zaman kaybı özellikle ölümcüldür
- Geliştirme ekibi organizasyonun stratejik hedeflerine odaklanmalı ve runway içinde teslimat yapmalıdır
- Her ekip üyesi, yaptığı işin hedeflerle uyumlu olup olmadığını düzenli olarak kontrol etmeli, gerekirse yeniden ayarlamalıdır
- Bir deney başarısız olsa bile, öğrenme için uygun yapı kurulmuş ve istenen ders çıkarılmışsa bu israf değildir
- Herkes birden fazla rol üstlenir
- Küçük organizasyonlarda yapılacak iş çoktur, ama bunları yapacak insan azdır
- Örneğin bir frontend geliştirici; ürün tasarımcısı, teknik yazar, ürün yöneticisi, kalite güvencesi sorumlusu veya üçüncü taraf entegrasyon sorumlusu gibi farklı rolleri de üstlenebilir
- Müşteri deneyimini iyileştirecek yeni bir fikir ortaya çıktığında, bunu öneren kişi prototipi bizzat üretmekten veya hayata geçirmekten sorumlu olabilir
- Bu kültürel özellikler, ürün geliştirme grubunun ve özellikle yazılım mühendisliği liderlerinin ihtiyaç duyduğu yetkinlikleri belirler
- Ayrıca DevOps, Platform Engineering ve Staff Engineering’in startup ortamına nasıl uyum sağlaması gerektiğine dair ipuçları verir
[Mühendislik ilkelerimi startup kültürüne uygulamak]
Startup’larda DevOps
- Startup’larda süreçleri değiştirmek kolaydır
- İnsan sayısı az olduğu için yeni çalışma biçimlerini uygulamanın önünde büyük engeller yoktur
- En iyi sonuçlar için süreçleri araçlara göre uyarlamak gerekir
- Katı süreçleri korumaya çalışmak, araçları özelleştirmeyi ya da ek yazılım geliştirmeyi gerektirdiği için zaman kaybına yol açar
- Özel geliştirilmiş araçlardan mümkün olduğunca kaçınılmalıdır
- Serverless altyapı, SaaS araçları ve açık kaynak kütüphanelerden yararlanmak tercih edilmelidir
- Teknolojinin genel akışına uyulmalı; farklılaştırıcı bir rekabet avantajı sunmuyorsa teknoloji özelleştirilmemelidir
- Bkz.: Martin Fowler’ın Utility vs Strategic Dichotomy
- "Sıkıcı teknoloji" seçilmelidir
- Ekibin aşina olmadığı veya etrafında yeterli topluluk bulunmayan çözümlere büyük risk yüklenmemelidir
- Sorun çıktığında internette çözümü kolayca bulunabilecek teknolojiler tercih edilmelidir
- Bu fikir, Dan McKinley’nin boringtechnology.club üzerindeki konuşmasında ayrıntılı olarak anlatılır
Startup’larda Platform Engineering
- Rebecca Murphey’nin Engineering Unblocked podcast yayınında geçen nokta:
- "Bir şirketin geliştirici deneyimi, tasarlanmış olsun ya da olmasın, bir üründür"
- Startup ölçeğinde bile izleme, dağıtım, hata takibi, log inceleme ve feature flag değiştirme gibi ihtiyaçlar devam eder
- Asıl önemli soru şudur: "Bu işler acı verici mi?"
- Platform Engineering startup’larda yarı zamanlı bir roldür
- Başlangıçta entegre bir test ortamı gerekebilir, ancak zamanla önceliği düşebilir
- Platform engineering rolü yalnızca ihtiyaç olduğunda devreye girer
- Uzun soluklu platform projelerine ayıracak lüks yoktur
- Bunun yerine küçük iş birimleri üzerinden değerli parçalar teslim edilmelidir
- Büyük resmi ve vizyonu ekiple paylaşmak gerekir, ancak küçük parçaların nasıl birleştiğini de görünür kılmak önemlidir
- Startup’larda platform çalışması, yeni üretkenlik ve yaklaşım biçimleri keşfetme sürecidir
- Mevcut yazılımdan modern araçlara geçişten çok, daha önce hiç var olmayan unsurların sıfırdan inşası söz konusudur
- Ne yapılabileceğinden çok, ne yapılması gerektiğine karar vermek önemlidir
- Mevcut organizasyon sorunlarını ya da yakın gelecekte ortaya çıkacak sorunları çözen işlere odaklanılmalıdır
- Gereken işler; pratik deneyim, mühendislerle yapılan görüşmeler, retrospektif geri bildirimleri ve SDLC (yazılım geliştirme yaşam döngüsü) metriklerinin analiziyle belirlenmelidir
- Bazen platform işlerini geri plana atıp başka ihtiyaçlara odaklanmak daha iyi olabilir
- Esnek yaklaşım kilit noktadır
Startup’larda Staff Engineering
- Staff Engineer rolü startup ortamına uygundur
- Derin teknik uzmanlık, geniş etki alanı arayışı ve iş problemlerini çözmek için ihtiyaç duyulan her yerde sorumluluk almaya istekli olma; startup’lara çok iyi uyar
- Büyük organizasyonlarda "teknik borcun nereye gömüldüğünü bilir" diye bir ifade vardır
- Staff Engineer bu bilgiye sahip kişiyi bulur, durumu netleştirir ve ilerlemek için kararlar çıkarır
- Startup’larda teknik borç ve sorunlar zaten açıkça görünür durumdadır
- Staff Engineer, bu karmaşayı düzene sokup uzun vadede organizasyona fayda sağlayacak çözümler kurarak büyük etki yaratabilir
- Startup’larda Staff Engineer tek bir arketip içinde kalamaz
- Organizasyon küçük olduğu için doğrudan uygulamayı da içeren çeşitli faaliyetleri üstlenmek gerekir
- Mimari tasarım, proje liderliği ve taktik işlerin yürütülmesinin yanı sıra, iyileştirme fikirlerini bizzat üretip uygulamak da gerekir
- Esneklik ve proaktif sahiplenme, startup’lardaki Staff+ mühendisler için vazgeçilmez özelliklerdir
- Staff+ mühendislerin önemli rollerinden biri mentorluk ve sponsorluktur
- Bu, özellikle startup’lardaki junior yeteneklere kritik destek ve yön sağlar
- Staff Engineer, bu destek sayesinde ekibin büyümesini hızlandırır ve organizasyonun yetkinliğini güçlendirir
[Startup’larda modern staff engineering uygulamak]
Hikaye 1 / 2 - "Improving DevEx by Removing a Merge Freeze"
Sorun durumu
- Mevcut QA süreci:
- Sürüm öncesinde 2-3 gün boyunca "merge freeze" uygulanıyor ve QA ekibi manuel regresyon testi yürütüyor
- Tespit edilen hatalar hemen düzeltilip main branch'e merge ediliyor
- Geliştiriciler yeni patch'ler build ediyor, ancak merge request'leri sürüm sonrasına kadar bekletmek zorunda kalıyor
- Dezavantajlar:
- Manuel regresyon testi yavaş ve öngörülemez
- Merge gecikmeleri, merge conflict oluşma sıklığını artırıyor
- Geliştirici üretkenliği ve iş birliği düşüyor
Çözüm
- Altyapı kodunu Monorepo içinde birleştirme
- Terraform projeleri, uygulama koduyla aynı repository içine alındı
- Otomatik linting ve bağımlılık yönetimi araçlarına bağlanarak geliştiricilerin altyapıyla daha kolay çalışması sağlandı
- Tüm ortamları Terraform ile yönetme
- Yalnızca yeni ortamlar değil, mevcut staging ve production ortamları da Terraform ile yönetildi
- Aynı altyapı tanımına farklı değişkenler uygulanarak ortamlar arası tutarlılık korundu
- CI/CD sürecini sadeleştirme
- Mevcut GitLab Auto DevOps şablonu, çok fazla özelleştirme nedeniyle karmaşık hale gelmişti
- Auto DevOps kaldırıldı ve yeni
.gitlab-ci.yml dosyası açık şekilde tanımlandı
- Komutların çoğu Makefile'a taşınarak manuel çalıştırma da mümkün kılındı
- Secrets yönetimini iyileştirme
- GitLab'a bağımlılığı azaltmak için uygulama secret'ları Google Cloud Secrets Manager'a taşındı
- Deployment script'leri, Kubernetes ConfigMap'i otomatik güncelleyecek şekilde değiştirildi
- Kapsam dışında bırakılan işler
- Uygulama, Kubernetes üzerinde çalışan bir monolith yapısında
- Bunu değiştirmek gecikme ve risk yaratabileceği için korundu
- Terraform otomasyon pipeline'ı kurulmadı
- Altyapı değişiklikleri görece az olduğundan manuel süreç sürdürüldü
- Kubernetes native secret erişim yaklaşımı da ertelendi
Sonuçlar ve kazanımlar
- Yeni bir test ortamı dağıtıldı ve QA ekibi regresyon testlerini bağımsız olarak yürütebilir hale geldi
- merge freeze'in kaldırılmasıyla geliştiriciler değişiklikleri özgürce main branch'e merge edebilir oldu
- Sürüm süreci sadeleşti ve tüm ekibin hızı arttı
Uygulanan ilkeler
- Staff Engineering ilkeleri
- Farklı ekiplerle iş birliği yaparak projeye liderlik edildi
- "Tech Lead" rolü üstlenilerek proje tamamlanmaya taşındı
- CI/CD ve altyapı iyileştirmeleriyle ekibin anlayışı ve erişilebilirliği artırıldı
- Platform Engineering ilkeleri
- DevOps projesi bir platform projesi haline gelecek şekilde genişletildi
- Tüm altyapı kod olarak yönetilerek ortamlar arası tutarlılık sağlandı
- Gerçekçi trade-off'lar ile proje kapsamı ayarlandı
- DevOps ilkeleri
- Altyapıyı kod olarak yöneterek bulut altyapısı tutarlı şekilde işletildi
- Sürüm süreci iyileştirildi ve yeni araçlarla geliştirme hızı artırıldı
- RFC(Request For Comment) belge formatı benimsenerek karar alma sürecinin kapsayıcılığı güçlendirildi
Sonuç
- QA ekibi, daha istikrarlı bir ortamda otomasyon testleri çalıştırabilir hale geldi
- Geliştiriciler merge freeze olmadan sürekli geliştirme yapabilir oldu ve iş birliği güçlendi
- Daha iyi tooling ve süreçler sayesinde organizasyonun üretkenliği arttı
- Gelecekte preview ortamları kurma ya da regresyon testlerini otomatikleştirme gibi ek çalışmalar yapılmak isteniyor
Hikaye 2 / 2 - "Iterating Towards a Productive Engineering Process"
Sorun durumu
- Mevcut süreç:
- Tüm ekip üyeleri tek bir board üzerinde çalışıyor ve her gün ilerleme durumunu paylaşıyordu
- Pek çok kişi sıra kendisinde değilken odağını kaybediyor ve "checkout" durumuna geçiyordu
- Özellik geliştirme sorumluluğu dağınıktı ve nihai sorumluluğu çoğu zaman ürün yöneticisi üstleniyordu
- Teknik mimariye dair net bir anlayış da eksikti
- Hedef:
- Daha iyi iş birliği ve yazılım geliştirme süreci kurmak için çeşitli deneyler yürütmek
- Deney 1: Kısa ömürlü özellik ekipleri (Short-lived Feature Teams)
- Amaç: Mühendislere özellik geliştirmenin tüm yaşam döngüsü için sahiplik vermek
- Yöntem:
- Her özellik için bir lider atanıp backend, frontend, QA gibi rollerden oluşan bir ekip kuruldu
- Sonuç:
- Ekip üyelerinin sahiplik duygusu gelişti, ancak herkes lider rolüne uygun değildi ya da bunu istemiyordu
- Sonrasında **"sabit ekip modeli"**ne geçilerek "Squads" oluşturuldu ve her ekip kendi planlama ile retrospektiflerini yürüttü
- Deney 2: Epic Kickoff Documents
- Amaç: Gereksinimleri netleştirmek ve projenin kapsamı ile yaklaşımı konusunda ekip içinde uzlaşı sağlamak
- Yöntem:
- Tüm ekip üyeleri, toplantıda sağlanan şablonu kullanarak belgeyi birlikte hazırladı
- Sonuç:
- Ekip içi iletişim gelişti ve projelerin en başından itibaren daha iyi iş birliği yapılmaya başlandı
- Ekip üyeleri bu toplantıyı değerli bir zaman kullanımı olarak değerlendirdi
- Deney 3: Grup kod incelemesi (Group Code Review)
- Amaç: Kod inceleme süresini kısaltmak, kod tartışmalarını canlandırmak ve mühendisler arasında teknik paylaşımı artırmak
- Yöntem:
- Haftada iki kez Slack Huddle üzerinde 1 saatlik kod inceleme oturumları düzenlendi
- Geliştiriciler ekranlarını paylaşarak PR'larını anlattı, katılımcılar da geri bildirim verdi
- Sonuç:
- Kod incelemeye harcanan süre ciddi ölçüde azaldı ve Inbox 0 durumu korundu
- Kod üzerine yapılan tartışmalar sayesinde geliştiricilerin birbirinden öğrendiği ve karşılıklı saygının oluştuğu bir kültür gelişti
- Kod incelemenin ötesinde, pair programming'in faydaları da ekibe tanıtıldı
Uygulanan ilkeler
- Staff Engineering ilkeleri
- Engineering manager olmadığında süreç iyileştirmelerine liderlik edildi
- Sürekli iyileştirme kültürü ekibe kazandırılarak çevik süreçler üzerinden otonom iş birliği güçlendirildi
- Ekibin tıkanmış süreçleri kırıp daha iyi yöntemler bulmasına destek verildi
- Platform Engineering ilkeleri
- Yalnızca araçların değil, süreçlerin de platformun bir parçası olduğu kabul edildi
- Verimsiz süreçlerin ekip üretkenliğini düşürdüğü görüldüğünden bunları iyileştirmek önemli sayıldı
- İsrafı ortadan kaldıran süreç değişikliklerinin, araç iyileştirmeleri kadar büyük etki yaratabileceği gösterildi
- DevOps ilkeleri
- CALMS ilkeleri: iş birliği(Collaboration), otomasyon(Automation), yalın(Lean), ölçüm(Measurement), paylaşım(Sharing)
- Yalın(Lean) süreçlerle israf ortadan kaldırılarak değer daha hızlı sunuldu
- Ekip, çevik süreçlerle sürekli iyileştirme yapacak şekilde eğitildi
Sonuç
- Ekibin süreçleri deneysel olarak iyileştirilirken üretkenlik ve iş birliği büyük ölçüde arttı
- Düşük maliyetli, yüksek etkili iyileştirmelerle tüm ekibin geliştirme deneyimi iyileşti
- Herkesin kendi süreçlerini eleştirel biçimde gözden geçirip iyileştirme alanları araması kuvvetle tavsiye ediliyor
[Kapanış]
- Startup ortamında çalışırken çeşitli sorunları çözüp çözümleri hayata geçirme sürecinde hem uzmanlığınızı hem de tutkunuzu ortaya koyabilirsiniz.
- Zaman kısıtları bulunduğu için pragmatik yaklaşımı geliştirmek adına iyi bir fırsattır ve şirketin ilk aşamalarında büyük etki yaratabilirsiniz.
- Modern yazılım mühendisliği yaklaşımlarını uygulayarak şirketin başarısının temelini atabilirsiniz.
-
Staff Engineering ve startup’lar
- Staff Engineer rolü, hem genişlik hem de derinlik içeren deneyim gerektirir.
- Startup’lar, Staff+ mühendislerine teknik bilgilerini genişletme ve yeni alanları keşfetme fırsatı sunar.
- Örnek: Bir backend mühendisi React veya BigQuery gibi teknolojileri öğrenebilir.
-
Platform Engineering ve startup’lar
- Startup’larda Platform Engineering, ölçeğe göre değişir.
- Bire bir iletişim yoluyla geliştiricilerin sorunlu noktalarını tespit edip, küçük projelerle geliştirici deneyimini (DevEx) iyileştirebilirsiniz.
- Hızlı geri bildirim döngüleri kurarak geliştirme sürecini iyileştirmek ve geliştiricilerin gelecekte sorunları kendi başlarına çözebilmelerine yardımcı olmak gerekir.
- Yazılım geliştirme yaşam döngüsünün (SDLC) temel gerekliliklerini sektör standardı araç ve tekniklerle karşılamak önemlidir.
- Startup’larda Platform Engineering, özel bir görev alanı değil, ihtiyaç oldukça uygulanan teknik bir yaklaşımdır.
- "Şirketin geliştirici deneyiminin bir ürün olduğunu" akılda tutmalı ve bunu tasarlamak için zaman ayırmalısınız.
-
DevOps ve startup’lar
- DevOps, startup’larda da çok önemli bir rol oynar.
- Özünde, kültür, süreç ve araçlar aracılığıyla müşterilere daha hızlı değer sunmak ve daha iyi bir çalışma ortamı yaratmak vardır.
- DevOps sayesinde şirketin verimliliğini artırmak ve iş birliği kültürünü yerleştirmek oldukça tatmin edici bir süreçtir.
- Startup’larda DevOps’a tutkuyla bağlı mühendisler, kendi beceri ve deneyimleriyle büyük katkı sağlayabilir.
- Startup ortamı yeni zorluklar ve öğrenme fırsatlarıyla doludur; bu sayede mühendisler daha da gelişebilir ve anlamlı sonuçlar ortaya çıkarabilir.
3 yorum
DevOps için bir ağıt
DevOps mühendisi'nden daha fazla kazanan platform mühendisi
Staff mühendisi nedir?
Bundan sonra startup’larda gerekli olan mühendislik rollerini iyi tanımlamış gibi görünüyor. Daha önce belirgin bir ayrım olmadan yapılan mühendislik işlerini iyi düzenlemiş gibi. Kişi de hangi mühendislik alanından sorumlu olduğunu ve gelecekte hangi alanda iyi olmak istediğini daha somut biçimde anlayabilecek gibi görünüyor. Startup’lar da sistemli bir mühendislik yapısı kurup ihtiyaç duydukları mühendisleri daha iyi seçebilir.