Staging Alanlarımızı Nasıl Yönetiyoruz?
Bir ekip olarak yazılım geliştirildiğinde, oluşan yazılım ürününün entegre ve test edilmesi gerekmektedir. Bu amaçla değişik türde staging alanları kullanılır. Bu yazımda yazılım ürünümüzün hangi staging alanlarından geçtikten sonra, canlı ortamı için bir sürüme dönüştürüldüğünü sizlerle paylaşmak istiyorum.
Öncelikle staging alanı nedir, onun bir kısa tanımlamasını yapalım. Bir staging alanı, uygulamanın entegre (snapshot, release candidate, release) edildikten sonra bir sunucu (server) üzerinde çalışır hale getirildiği ortamdır. Bizim örneğimizde backend olarak tabir ettiğimiz Java ve Spring boot bazlı uygulamayı, uygulamanın değişik evrelerinde kendi sunucularımızda çalışır hale getiriyor ve test ediyoruz. Her staging alanı uygulamanın belli bir olgunluk safhasına işaret etmektedir. Oluşturulan sürüm bu ortamları tek tek geçerek, olgunlaşır (hatasız hale gelir) ve sonunda canlı (production) ortamı için kullanılabilir hale gelir.
Staging alanları aracılığı ile uygulama değişik evrelerinde sürükli entegre olmuş ve kullanıma hazır vaziyette tutulur. Bu şekilde değişik ekipler uygulamanın yeni sürümlerini kendi koşullarına uygun bir şekilde test edebilirler.
Kullandığımız staging alanlar şu şekilde:
Development
Yazılım ekbimiz uygulayı geliştirmek için git kullanıyor. Develop ismini taşıyan branch kodun entegre ve test edilmiş son halini ihtiva ediyor. Uygulamaya yeni bir özellik eklemek için ekip arkadaşlarımız feature branch oluştuyorlar ve gerekli değişiklikleri bu branch içinde yapıyorlar. Bu kodun develop branch’ına geri dönebilmesi için bir PR (pull request) oluşturulması gerekiyor. PR aracılığı ile yeni feature branch bünyesinde geliştirilmiş olan kodu incelemek (code review) mümkün. Bu şekilde yazılan her satır kod tüm ekip tarafından kontrol edilebilir hale geliyor.
Her PR için en az bir ekip arkadaşımızın review yaparak, onay (approval) vermesi gerekiyor. Onay almayan PR’in develop branch ile birleştirilmesi (merge) mümkün değil. Onay alındıktan, PR develop branch ile merge edildiken ve Github Actions aracılığı ile entegre edildikten sonra kodun entegrasyon testleri ile test edilmesini ve akabinde gerekli sunucu ortamına kurulmasını (deployment) sağlıyoruz. Bu işlem her PR squash commit sonrasında otomatik olarak yapılıyor ve entegre ve test edilmiş snapshot sürüm development sunucusuna kuruluyor. Bu bizim dev.vellkam.local olarak tanımladığımız ilk staging alanımız. Bu sadece yazılımcılar tarafından entegrasyon amaçlı kullanılan bir staging ortamı. Her yeni commit ile bu alan yıkılıyor ve yeniden yapılandırılıyor. Entegrasyon esnasında bir hata oluşması durumunda, bu ekibe Mattermost kanalları üzerinden bildiriliyor. Bu şekilde hatayı kısa sürede bulmak ve düzeltmek mümkün hale geliyor.
Kullanım amacı ve kullanıcı topluluğu: Dev staging alanı yazılımın en son hali ile ilk entegre ve test edildiği yerdir. Bu alan yazılımcı ekibe aittir ve ekip bu alanın sürekli ayakta olmasından sorumlu değildir. Bu alan gün içinde sürekli yeniden yapılandırılır. Yazılım ekibi harici kimse bu alanı stabil olmadığı için kullanmaz. Bu alan entegrasyon hatalarını tespit etmek ve gidermek için kullanılır.
Feature
Geliştirdiğimiz backend web tabanlı bir arayüze ve rest bazlı bir APİ’ye sahip. Bu yazılım ürününü daha önce de bahsettiğim gibi git feature branch mekanizması ile geliştiriyoruz. Henüz merge edilmemiş bir feature branch’in dev.vellkam.local staging alanında çalışır hale getirilmesi mümkün değil, çünkü bunun için önce develop branch ile merge edilmesi yani PR’in kabul görmüş ve onaylanmış olması gerekiyor. Bazı şartlar altında feature branch bünyesinde çalışan ekip arkadaşlarımız yaptıkları değişiklikleri PR öncesinde ekip arkadaşları ile paylaşmak isteyebiliyorlar. Bu durumda mevcut kodun feature branch üzerinden feature.vellkam.local olarak isimlendirdiğimiz feature staging alanına entegre edilerek, aktarılması mümkün. Bu staging alanında kurulumu kolaylaştırmak için testler devre dışı bırakılıyor, çünkü bu branch içindeki kod stabil olmadığı için testler çalışır durumda olmayabiliyor. Ayrıca amaç hızlı bir kurulum gerçekleştirmek ve uygulamayı çalışır halde görmek olduğu için kodun stabil ya da testlerin çalışır durumda olması önem taşımıyor.
Kullanım amacı ve kullanıcı topluluğu: Henüz gelişimi tamamlanmamış lakin görücüye çıkmak zorunda olan ve dev.vellkam.local staging alanı için hazır olmayan kodun kurulumunun yapıldığı alandır ve sadece kurulumu yapan yazılımcıya aittir. Ekip içinde koordinasyonu gerektiren bir staging alanıdır, çünkü diğer ekip çalışanları da kendi feature branch’larını bu alana aktarmak isteyebilirler.
Test
Bazı şartlar altında feature branch içinde olan kodun dev staging alanına çıkmadan ne oranda stabil olduğunu anlamak ve test etmek için test.vellkam.local ismini taşıyan staging alanı kullanılabilmektedir. Bu staging alanı aslında feature staging alanı ile aynı özelliklere sahiptir. Test staging alanı kurulumlarında feature staging alanına nazaran tüm testler çalıştırılır. Bu özellik aslında sadece dev.vellkam.local alanında mevcut iken, yazılımcılarımız istedikleri zaman dev staging alanı konforunda üzerinde çalıştıkları kodu entegre ve test ederek, kurulumunu gerçekleştirebilmektedirler.
Kullanım amacı ve kullanıcı topluluğu: Kodun develop branch ile merge edilmesi mümkün olmadığında lakin tam entegrasyon ve testlerin çalışırlığı kontrol edilmek istenmesi durumunda yazılımcılar tarafından kullanılabilen bir staging alanıdır. Ekip içinde koordinasyonu gerektiren bir staging alanıdır, çünkü diğer ekip çalışanları da kendi feature branch’larını bu alana aktarmak isteyebilirler.
Integration
Yazılım ürünü belli aşamalarda yazılım durdurularak (code freeze) sürümlenmek zorundadır. Bu sürümler otomatik ve elden yapılan testler neticesinde belli bir olgunluğa ulaşırlar. Bunun sağlandığı ilk ortam integration (int.vellkam.local) staging alanıdır. Daha sonra canlı da çalışır hale gelecek sürümler dünyaya gözlerini bu ortamda açarlar. Biz örneğin çalışmalarımızı tamamladığımızda develop branch içinde yer alan kodu integration branch ile merge ediyoruz. Bu aslında oluşacak yeni bir sürüm için start verilmesi anlamına geliyor. Merge işlemi gerçekleştikten sonra yeni bir sürüm oluşturularak, int.vellkam.local staging alanına kuruluyor.
Kullanım amacı ve kullanıcı topluluğu: Sürümün ilk versiyonu burada test edilir. Stabil bir ortamdır. Özellikle test ekibi tarafından tercih edilen ilk staging alanıdır. Yeni sürümü test etmek için kullanılır. Bu ortam stabil kalmak zorundadır, çünkü test ekibi ve diğer çalışanlar sürekli sorunsuz çalışabilecekleri bir ortama ihtiyaç duyarlar. Bu ortamın sahibi artık yazılımcı ekibi değildir. Yazılımcı ekibi sadece yeni sürümler oluşturmak ve bunların kurulumunu yapmakla sorumludur.
UAT
User acceptance testing anlamına gelen bu staging alanı bir alt staging olan integration staging alanından gelen sürümlerin son hali ile kurulumunun ve testlerinin yapıldığı ortamdır. Bu ortam canlı (production) ortamının bir kopyasıdır. Genelde canlı veritabanı anonomize edilerek bu ortamda kullanılır. Bunu yani sıra teknik anlamda bu staging alanı canlının birebir kopyasıdır, çünkü bu alanda kurulumu yapılan uygulamanın canlı şartlarında test edilmesi gerekmektedir. Bizim sürümlerimiz için uat.vellkam.local sunucularını kullanıyoruz. Buraya kadar gelmiş olan bir sürüm son testleri yapıldıktan ve mevcut hatalar giderildikten sonra vellkam.com production staging alanında kullanılabilir bir sürüm haline gelmektedir.
Kullanım amacı ve kullanıcı topluluğu: Sürümün en son ve en stabil halinin deploy edildiği staging alanıdır. Bu alan canlı öncesi son duraktır. Entegrasyonu ve testleri başarıyla tamamlanan bir sürüm buradan canlıya alınır.
Production
Yeni bir sürümün çalışır hale getirildiği en son ve canlı olarak isimlendirilen staging alanıdır.
Ekip işi olan yazılım aynı zamanda değişik çalışma alanlarına da ihtiyaç duymaktadır. Bu yazımda bizim kullandığımız ama genel geçerliliğe sahip staging alanları konseptini sizlerle paylaştım. Bu listeye performans ve yük testlerinin (load testing) yapıldığı staging alanlarını da eklemek mümkün. Aynı şekilde birçok projede veritabanları (örneğin Oracle) için de bu tür staging alanlarının kullanıldığına şahit oldum, çünkü orada da her yeni sürümün önce test edilmesi gerekmektedir.
Bir sürümün olgunlaşabilmesi için değişik staging ortamlarından geçmesi gerekmektedir. Sadece bu şekilde uygulama bünyesindeki hataları keşfetmek ve gidermek mümkün hale gelmektedir.
EOF (End Of Fun)
Özcan Acar