Tətbiqlərin hazırlanmasında Staging: nədir, vəzifələri və mühitin konfiqurasiyası

Staging mühiti nədir

Staging — produksiyaya yerləşdirmədən əvvəl yekun yoxlama platforması kimi xidmət edən mühitdir. Tərtibat və test mühitlərindən fərqli olaraq, staging real istismar şəraitinə maksimum yaxındır: eyni OS versiyaları, oxşar şəbəkə konfiqurasiyası, yaxın data həcmləri və eyni xarici inteqrasiyalardan istifadə edir.

Staging-in əsas məqsədi yalnız real istismar şəraitinə yaxın şəraitdə üzə çıxan problemləri aşkar etməkdir. Məsələn, yüksək yük altında race condition, asılılıq versiyalarının uyğunsuzluğu, produksiya dataları ilə edge case-lərin səhv emalı.

Microsoft DevOps Practices, 2025-ə görə, staging mühitindən müntəzəm istifadə change failure rate-i — uğursuz yerləşdirmələrin faizini azaldan ilk 5 təcrübədən biridir. Staging mərhələsini keçən komandalar kritik insidentlərlə 3-4 dəfə daha tez-tez qarşılaşırlar.

CI/CD pipeline-nın bir hissəsi kimi Staging

Yetkin pipeline-da staging avtomatlaşdırılmış test mərhələsindən sonra gəlir və produksiyadan əvvəl yerləşir. Əvvəlki bütün yoxlamalardan uğurla keçmiş artefakt staging-də yerləşdirilir, burada end-to-end ssenarilər, yük testləri və əl ilə qəbul (tələb olunarsa) həyata keçirilir.

Staging və digər mühitlər

İnkişaf mühitləri arasındakı fərqləri anlamaq testi mərhələlər üzrə düzgün bölüşdürməyə kömək edir. Hər bir mühit öz vəzifələrini həll edir və müxtəlif yoxlama vasitələrindən istifadə edir.

Staging və QA mühiti arasında əsas fərqlər

QA mühiti adətən sintetik datalar ehtiva edir və memarlıq baxımından produksiyadan fərqlənə bilər (məsələn, daha az verilənlər bazası replikası). Staging isə tam paritetə can atır: eyni xidmət versiyaları, eyni verilənlər bazası ölçüsü (datada anonimləşdirilsə də), eyni şəbəkə mühiti.

Staging nə zaman lazım deyil

Etibarlılığa tələbləri aşağı olan sadə layihələr üçün ayrıca staging mühitinin saxlanması xərcləri özünü doğrultmaya bilər. Belə hallarda staging rolunu produksiyaya yaxın dataları olan QA mühiti oynaya bilər. Lakin yüksək SLA (99.9%+) olan layihələr üçün staging məcburidir.

Staging-də nə test edilir

Staging mühiti erkən mərhələlərdə aparıla bilməyən və ya səmərəsiz olan yoxlamalar üçün nəzərdə tutulub. Hər bir test növü spesifik kateqoriya defekt aşkar edir.

End-to-end (E2E) testlər

Sistemin bütün komponentlərindən keçən tam istifadəçi ssenariləri: mobil tətbiq -> API -> verilənlər bazası -> xarici xidmətlər. Mobil tətbiqlər üçün E2E testlərinə qeydiyyat, avtorizasiya, ödənişlər, push bildirişləri daxildir. Alətlər: Detox, Appium, Espresso, XCUITest.

Yük testi

Staging — realist yüklə performans testini aparmaq mümkün olan yeganə mühitdir. İstifadə olunan alətlər: JMeter, k6, Gatling. Məqsəd — tətbiqin gözlənilən RPS (requests per second) dərəcəsinə tab gətirdiyini yoxlamaq və əvvəlki buraxılışla müqayisədə deqradasiyanı aşkar etməkdir.

Real asılılıqlarla inteqrasiya testi

Staging-də xidmətlər mock-larla deyil, xarici sistemlərin real (və ya sandbox) versiyaları ilə ünsiyyət qurur. Ödəniş şlüzləri, email/SMS göndərilməsi, analitik trekerlər — bütün inteqrasiyalar produksiyaya maksimum yaxın şəraitdə test edilir.

// Staging mühiti üçün Retrofit konfiqurasiyası nümunəsi
object ApiClient {
    private fun getBaseUrl(): String {
        return when (BuildConfig.FLAVOR) {
            "staging" -> "https://api.staging.example.com/"
            "production" -> "https://api.example.com/"
            else -> "https://api.dev.example.com/"
        }
    }

    val api: ApiService = Retrofit.Builder()
        .baseUrl(getBaseUrl())
        .build()
        .create(ApiService::class.java)
}

Staging-də data idarəetməsi

Staging-də datalar mühitin qurulmasının ən çətin aspektlərindən biridir. Bir tərəfdən etibarlı test üçün produksiyaya mümkün qədər yaxın olmalı, digər tərəfdən təhlükəsizlik və məxfilik tələblərinə əməl edilməlidir.

PII-nin anonimləşdirilməsi və maskalanması

İstifadəçilərin şəxsi dataları (email, telefon, ünvan, ödəniş məlumatları) staging-ə kopyalanmazdan əvvəl anonimləşdirilməlidir. Deterministik şifrələmə və ya sintetik datalarla əvəz etmədən istifadə edin. Alətlər: Delphix, Tonic, maskalanmış dəyərlərlə UPDATE üçün SQL skriptləri. Maskalanmanın biznes məntiqini pozmadığına əmin olun — məsələn, email məktub göndərilməsi testi üçün etibarlı formatda qalmalıdır.

Verilənlər bazası sxeminin sinxronizasiyası

Staging verilənlər bazasının strukturu miqrasiyalar zamanı avtomatik yenilənməlidir. Sxem versiyalaşdırması üçün Liquibase və ya Flyway-dən istifadə edin. Miqrasiyalar ardıcıl olaraq bütün mühitlərə tətbiq olunur: dev -> QA -> staging -> production. Staging və produksiya arasında sxemdə hər hansı uyğunsuzluq testin etibarlılığını azaldır.

Data həcmi və performans

Staging-də produksiya datalarının tam həcmini saxlamaq məcburi deyil. Performans testi üçün bütün əsas ssenariləri əhatə edən nümayəndə seçmə kifayətdir. Lakin miqyaslama problemlərini aşkar etmək üçün data həcminin minimum test həddindən ən azı 3-5 dəfə çox olduğundan əmin olun. Tam z dump əvəzinə yalnız əlaqəli data alt çoxluqlarını kopyalamaq üçün subsetting-dən istifadə edin.

# Staging üçün data anonimləşdirmə skripti
import hashlib

def anonymize_email(email):
    local, domain = email.split('@')
    hash_local = hashlib.sha256(local.encode()).hexdigest()[:10]
    return f"{hash_local}@{domain}"

# UPDATE users SET email = CONCAT(
#   SUBSTR(SHA2(email, 256), 1, 10), '@', SUBSTR(email, LOCATE('@', email) + 1)
# );

Staging mühitinin qurulması

Staging mühitinin yaradılması produksiyaya dəqiqlik və infrastruktur xərcləri arasında tarazlıq tələb edən bir vəzifədir. Mikroservis memarlığına malik mobil layihə üçün addım-addım yanaşmanı nəzərdən keçirək.

Addım 1: Mühit tərkibinin müəyyən edilməsi

Produksiyanın hansı komponentlərinin staging-də olması lazım olduğunu müəyyənləşdirin: API şlüzü, server hissəsi (mikroservislər), verilənlər bazaları, keş (Redis), növbələr (RabbitMQ/Kafka), fayl anbarı (S3-compatible). Tam paritet üçün eyni orkestratordan (Kubernetes) analoji replika sayı ilə istifadə edin.

Addım 2: Staging-ə yerləşdirmə üçün CI/CD qurulması

Pipeline-a uğurlu testlərdən sonra yerinə yetirilən "Deploy to Staging" mərhələsi əlavə edilir. Tətbiq konfiqurasiyası (URL endpointlər, sandbox xidmətləri üçün API açarları) mühit dəyişənləri və ya CI sisteminin sirləri vasitəsilə ötürülür.

Addım 3: Dataların anonimləşdirilməsi və sinxronizasiya

Realist test üçün staging produksiyaya bənzər datalar ehtiva etməli, lakin məxfi məlumatlar olmamalıdır. Dövri olaraq (gündəlik/həftəlik) produksiya datalarını kopyalayan, PII (şəxsi dataları) anonimləşdirən ETL prosesi qurun.

• Database seeding — bütün biznes ssenarilərini əhatə edən staging üçün test dataları ilə doldurma skriptləri
• Secrets management — produksiya ilə üst-üstə düşməyən staging üçün ayrıca açarlar (Vault, AWS Secrets Manager)
• Network policies — staging internetdən əlçatan olmamalı və ya ciddi IP ağ siyahısına malik olmalıdır

Staging üçün ən yaxşı təcrübələr

Staging mühitindən səmərəli istifadə müəyyən qaydalara riayət etməyi tələb edir. Bu qaydaların pozulması staging-in dəyərini sıfırlayır və yalançı təhlükəsizlik hissi yaradır.

Produksiya ilə paritet

Staging bütün parametrlərə görə produksiyaya mümkün qədər yaxın olmalıdır: OS versiyaları, şəbəkə gecikmələri, data həcmi, xidmət nüsxələrinin sayı. Əgər staging produksiyadan fərqlənirsə, onun üzərində test nəticələri reallığa uyğun olmaya bilər.

Digər mühitlərdən izolyasiya

Staging ayrıca verilənlər bazası, ayrıca keş və ayrıca növbələrdən istifadə edir. Mühitlərin qarışdırılması gözlənilməz vəziyyətlərə gətirib çıxarır: tərtibatçı təsadüfən test datalarını silə və ya reqressiya test nəticələrinə təsir edə bilər.

Avtomatik təmizləmə

Hər test mərhələsindən sonra staging əsas vəziyyətə (clean state) qayıtmalıdır. Infrastructure as code üçün Terraform və ya Pulumi-dən istifadə edin — bu, mühiti bir əmrlə yenidən yaratmağa və onun eyniliyini təmin etməyə imkan verir.

Monitorinq və xəbərdarlıq

Staging-də produksiyadakı kimi eyni monitorinq stack işləməlidir: loqlama (ELK, Loki), metrikalar (Prometheus, Datadog), treysinq (Jaeger, Zipkin). Staging monitorinq olunmursa, orada aşkar edilən problemlər diqqətdən qaça bilər.