DevOps nedir?
DevOps, yazılım geliştirme (Development) ile sistem işletimi (Operations) arasındaki duvarı kaldırmayı hedefleyen bir çalışma kültürü ve pratikler bütünüdür. Geleneksel düzende geliştirici kodu yazar, başka bir ekip veya kişi onu sunucuya taşır; bir sorun çıktığında iki taraf birbirine bakar. DevOps’ta ise kodun yazılmasından canlıda sorunsuz çalışmasına kadar olan süreç, ortak sorumluluk ve otomasyonla tek bir akış hâline getirilir.
Somut olarak DevOps şu sonuçları hedefler:
- Değişikliklerin küçük parçalar hâlinde ve daha sık yayına alınması.
- Her yayının otomatik testlerden geçmesi ve aynı adımlarla tekrarlanabilmesi.
- Bir sorun çıktığında hızlıca fark edilmesi ve bir önceki sürüme dönülebilmesi.
- Sunucu ve ayarların belgelenmemiş el işçiliği yerine tanımlı ve tekrar üretilebilir olması.
DevOps ve Agile: aynı şey mi?
Hayır, ama birbirini tamamlarlar. Agile, ne geliştirileceğine kısa döngülerle ve kullanıcı geri bildirimiyle karar verme yöntemidir. DevOps ise geliştirilenin nasıl güvenle teslim edileceği ve çalışır tutulacağı ile ilgilenir. Agile bir ekibin iki haftada bir yeni özellik hazırlamasını sağlar; DevOps pratikleri yoksa bu özellikler aylarca yayın sırası bekleyebilir ya da her yayın bir krize dönüşebilir.
Temel kavramlar
Sürüm kontrolü
Kodun ve mümkünse sunucu ayarlarının Git gibi bir sürüm kontrol sisteminde tutulması. Kimin neyi, ne zaman ve neden değiştirdiği kayıt altına alınır; her değişiklik geri alınabilir. DevOps’un diğer tüm adımları bu temele dayanır.
Sürekli entegrasyon (CI)
Her kod değişikliğinin ana dala eklenmeden önce otomatik olarak derlenmesi ve test edilmesi. Hatalar, yayın gününe değil değişikliğin yapıldığı güne yakalanır.
Sürekli teslimat ve dağıtım (CD)
Testten geçen kodun tek bir komutla (sürekli teslimat) veya tamamen otomatik olarak (sürekli dağıtım) yayına alınması. Amaç, yayını sıradan ve sıkıcı bir işlem hâline getirmektir.
Kod olarak altyapı (IaC)
Sunucuların, ağ kurallarının ve servislerin elle tıklanarak değil, sürüm kontrolündeki dosyalarla tanımlanması. Bir sunucu kaybolduğunda aynısını dakikalar içinde yeniden kurabilmek bu sayede mümkün olur.
İzleme ve kayıt
Uygulamanın ve sunucunun sağlığının sürekli ölçülmesi: yanıt süresi, hata oranı, disk ve bellek kullanımı. Sorunları müşteriden önce fark etmenin tek yolu budur.
KOBİ’ler için gerçekçi bir başlangıç yol haritası
DevOps’u benimsemek için büyük bir dönüşüm projesine gerek yoktur. Aşağıdaki adımlar sırayla, her biri bir öncekinin üzerine kurularak uygulanabilir:
- Tüm kodu sürüm kontrolüne alın. Sunucuda doğrudan dosya düzenlemeyi bırakın. Tek bir ana dal ve kısa ömürlü özellik dalları çoğu küçük ekip için yeterlidir.
- Gizli bilgileri koddan ayırın. Veritabanı parolaları ve API anahtarları depoya değil, ortam değişkenlerine veya bir gizli bilgi kasasına ait olmalıdır.
- Bir test ortamı kurun. Canlıya benzeyen, gerçek müşteri verisi içermeyen bir ortam; değişiklikler önce burada denenir.
- Dağıtımı otomatikleştirin. Elle dosya kopyalama yerine tek bir betik veya CI/CD hattı: kodu al, testleri çalıştır, paketi oluştur, yayına al.
- Geri alma yolunu garanti edin. Her yayından önce otomatik yedek alın ve bir önceki sürüme tek adımda dönebildiğinizi test edin.
- İzleme ve uyarı ekleyin. Site çöktüğünde, hata oranı arttığında veya disk dolmak üzereyken birine bildirim gitsin.
- Küçük ve sık yayına geçin. Ayda bir büyük yayın yerine haftada birkaç küçük yayın. Hata çıktığında nedeni bulmak çok daha kolay olur.
Neyi ölçmelisiniz?
DevOps’un işe yarayıp yaramadığını anlamak için yaygın olarak kullanılan dört ölçüt (DORA ölçütleri olarak bilinir) küçük ekipler için de anlamlıdır:
- Yayın sıklığı: Ne sıklıkla canlıya değişiklik alabiliyorsunuz?
- Değişiklik süresi: Bir kod değişikliğinin yazılmasından canlıya çıkmasına kadar geçen süre.
- Başarısız değişiklik oranı: Yayınların ne kadarı soruna veya geri almaya yol açıyor?
- Hizmete dönüş süresi: Bir sorun çıktığında sistem ne kadar sürede normale dönüyor?
Bu sayıları bugünden not edin. Üç ay sonra aynı ölçümle karşılaştırmak, yapılan yatırımın karşılığını somut olarak gösterir.
Sık yapılan hatalar
- Araçla başlamak: Karmaşık bir konteyner orkestrasyon platformu kurmak, temel dağıtım süreci hâlâ elle yapılıyorsa sorunu çözmez.
- DevOps’u tek bir kişiye yüklemek: “DevOps mühendisi” tek başına süreci taşıyorsa, o kişi izne çıktığında yayınlar da durur. Amaç bilgiyi otomasyona ve belgeye taşımaktır.
- Testleri atlamak: Otomatik test olmadan otomatik dağıtım, hataları daha hızlı yayına almak demektir.
- Güvenliği sona bırakmak: Bağımlılık taraması, gizli bilgi kontrolü ve yetki sınırları hattın en başına eklenmelidir.
Mevcut yayın sürecinizi değerlendirip sürüm kontrolü, otomatik dağıtım, yedek ve geri alma adımlarını kurmak isterseniz DevOps ve sürüm yönetimi hizmetimize göz atabilirsiniz. Web sitenizin güncelleme ve güvenlik düzeni için web sitesi bakımı sayfamız da ilginizi çekebilir.
Sık sorulan sorular
DevOps için büyük bir ekip gerekir mi?
Hayır. Tek geliştiricili projeler bile sürüm kontrolü, otomatik test ve tek komutla dağıtım gibi temel pratiklerden fayda görür. Önemli olan ekip büyüklüğü değil, tekrarlanabilir ve geri alınabilir bir yayın sürecidir.
DevOps ile Agile arasındaki fark nedir?
Agile, neyin ve hangi sırayla geliştirileceğini kısa döngülerle yönetir. DevOps ise geliştirilenin güvenle yayına alınmasını ve çalışır durumda tutulmasını sağlar. Agile hızlı karar vermeyi, DevOps o kararı hızlı ve güvenli teslim etmeyi hedefler.
İlk olarak neyi otomatikleştirmeliyim?
Genellikle en iyi başlangıç, elle yapılan ve hata çıkaran dağıtım adımıdır. Kodun sürüm kontrolünden tek bir komutla test edilip yayına alınması ve bir önceki sürüme dönülebilmesi, diğer tüm iyileştirmelerin temelidir.