DevOps danışmanlığının çıktısı yalnızca bir otomasyon aracı kurulumu olmamalıdır. Asıl ihtiyaç, yazılım değişikliğinin geliştirmeden üretime nasıl geçtiğini görünür ve tekrarlanabilir hale getirmektir. Her şirketin Kubernetes veya çok sayıda yeni araca ihtiyacı yoktur. Başlangıç noktası, mevcut dağıtım sürecindeki gecikmeler ve hataya açık adımlardır.
Önce bugünkü dağıtımı haritalayın
Son birkaç sürümün nasıl yayınlandığını inceleyin. Kodu kim onayladı, paket hangi ortamda üretildi, ayarlar nasıl taşındı ve hata olduğunda ne yapıldı? Elle yapılan işlemleri, tek kişiye bağlı bilgileri ve kayıt tutulmayan kararları belirleyin. Dağıtım sayısı az olsa bile üretime hangi sürümün çıktığının bilinmemesi önemli bir işletim sorunudur.
İlk pipeline ne yapmalı?
- Kod değişikliğini sürüm kontrolünden belirli bir tetikleyiciyle alın.
- Bağımlılıkları tanımlı sürümlerle hazırlayın ve paketi oluşturun.
- Projeye uygun otomatik kontrolleri çalıştırın.
- Aynı paketi test ortamına dağıtıp temel iş akışını doğrulayın.
- Üretim onayı ve dağıtım kaydı oluşturun.
- Dağıtım sonrası sağlık kontrolünü ve geri dönüş koşulunu çalıştırın.
Bu liste her proje için aynı testleri gerektirmez. Bir API ile masaüstü uygulamasının doğrulaması farklıdır. Öncelik, sık hata üreten ve iş açısından kritik olan adımları güvenilir hale getirmektir. Otomatik kontrolün neyi doğruladığı ve neyi kapsam dışında bıraktığı da belgelenmelidir.
Ortam ve sır yönetimini ayırın
Test ve üretim bağlantıları, erişim yetkileri ve onayları birbirine karışmamalıdır. Parolaları veya erişim anahtarlarını kaynak koduna yazmayın. Pipeline hesabına işinin gerektirdiği yetkiyi verin ve gereksiz erişimleri kaldırın. Logların hassas bilgileri açığa çıkarıp çıkarmadığını da kontrol edin.
GitHub Actions deployment environments, ortam bazında onay, dal kısıtlaması ve sır erişimi gibi kontroller sunar. Kullanılan araç farklı olsa da tasarım sorusu aynıdır: Hangi sürümün hangi ortama, kimin onayıyla ve hangi yetkiyle gideceği belirli mi?
Geri dönüşü dağıtımdan önce tasarlayın
Önceki uygulama paketine dönmek, veritabanı değişikliğini otomatik olarak geri almaz. Şema geçişleri, veri dönüşümleri ve dış servis uyumluluğu ayrıca planlanmalıdır. Varsayımsal bir örnekte yeni sürüm bir alanı kaldırıyorsa eski uygulamanın o alanı bekleyip beklemediği test edilmelidir. Kritik değişikliklerde geri dönüş yerine düzeltici ileri dağıtım gerekebilir; karar önceden alınmalıdır.
Başarıyı araç sayısıyla ölçmeyin
Yayın hazırlama süresini, başarısız dağıtımları ve sorun sonrası toparlanmayı izleyin. Sayıları ekipleri yarıştırmak için değil, darboğazı bulmak için kullanın. İlk hedef bir pilot uygulamada tekrarlanabilir dağıtım ve anlaşılır işletim kaydı olabilir. Sonraki uygulamalara yayılım, pilotun gerçek sonuçlarına göre yapılmalıdır.
DevOps için buluta geçmek şart mı?
Hayır. Sürüm kontrolü, otomatik test, kontrollü dağıtım ve gözlemlenebilirlik şirket içi sistemlerde de uygulanabilir. Altyapı seçimi uygulamanın ihtiyaçlarından ayrı değerlendirilmemelidir.
CieloSync DevOps ve otomasyon hizmeti kapsamında mevcut sürecinizi değerlendirebilir; platform seçimi için VM, container ve Kubernetes rehberine bakabilirsiniz.