Ana içeriğe atla

DevOps Yolculuğum - 1 - Continous Delivery


DevOps Yolculuğum

2018 yılıyla birlikte kariyerime DevOps Mühendisi olarak devam edeceğim. Bu zamana kadar IT altyapı ve operasyon ekiplerinde kazandığım, server operasyon ve yönetimi, veritabanı operasyon ve yönetimi, uygulama operasyon ve geliştirme deneyimlerimi DevOps için kullanacağım. Bu süreçte fırsat buldukça DevOps adına öğrendiklerimi blog yazılarımda toparlamayı hedefliyorum. Umarım hem yeni kariyer hedefimde hem de blog zinciri hedefimde başarılı olabilirim:)

Bu zincirdeki ilk yazımda Continous Delivery mekanizmasından bahsetmeyi düşündüm. Umarım bana ve okuyan herkese faydası dokunur.

Continous Delivery Nedir?

Continous Delivery temelde software release sürecinin tamamını etkileyen yazılım mühendisliği yaklaşımıdır. Test otomasyonu, uygulama deploymentlarının otomasyonu ve development sırasında kullanılan süreçlerin otomasyonu Continous Delivery'nin önemli bileşenleridir. Continous Delivery'in temel hedefi büyük ölçekli dağıtık ortamlara, kompleks production ortamlarına predict edilebilir deployment yapabilmektir. Bu hedefe ulaşabilmek için development sırasında en başta tekrarlayan süreçlerimiz olmak üzere süreçlerimizin mümkün olan adımlarını otomasyona uyumlu olarak tekrar dizayn etmeli, development ortamından test ortamına kodu otomatik deploy edebilmeli, test ortamındaki testlerimizi de insan hatasını ortadan kaldırabilmek için yine test otomasyon toollarıyla yapabilmeliyiz. Bileşenlerden bir tanesinin otomasyon yerine manuel süreçlerle ilerlemesi, hataya yol açabileceğinden dolayı bu bileşenlerin herhangi birisinin CD süreçlerinin içerisinden çıkarılması düşünülemez. 
Tüm bunlar organizasyonel yapıda ciddi değişikliklere gidilmesini, kişilerin bu yapıya uygun çalışma yapılarını da düzeltmesini gerektirmektedir. Bir uygulama release'ine ve deployment'ina dokunan herkes bu sürece uyumlu çalışmalıdır. 
Özetle Continous Delivery, deployment ve release süreçlerinde çeviklik (agility) ve hızı (velocity) arttırmak adına ortaya çıkarılmış bir mekanizmadır. 
 
Peki neden Continous Delivery mekanizmasını software release süreçlerimize entegre etmeliyiz?
  • CD'nin birincil hedefi uygulama deploymentlarının daha az sancılı ve esnek olabilmesini sağlamaktır. Zero-downtime hedefine ulaşabilmeyi hedefler.
  • Daha çevik ve hızlı yazılım geliştirmesiyle pazarda öncü olmayı hedefler. 
  • Süreçleri hatasız devam eden bir sowftware release döngüsüyle daha kaliteli kod hedefler.
  • Otomasyon süreçleri sayesinde tekrarlayan işlerde harcanan kaynaklar boşa çıkacağı için aslında daha düşük kaynak kullanımını hedefler.
  • Operasyonel ve tekrarlayan işlerden uzaklaşan takımların daha üretken ve mutlu olmasını hedefler.








Yorumlar

Bu blogdaki popüler yayınlar

gMSA (group managed service account) and SQL Server

MSA (managed user account) teknolojisinin sorunlarından bir tanesi aynı MSA'i birden fazla computer objesinde kullanamamaktı. Bu nedenle de gMSA (group managed service account) duyuruldu. gMSA ile; Passwordler Active Directory tarafından yönetileceği için complex olurlar ve sık sık otomatik olarak değiştirilir (default 30 days). Passwordler 240 bytes uzunluğunda randomly şifrelenmiş olarak üretilir. Ek olarak interactive logon amaçlı kullanılamazlar, yanlış şifre girilmesi sonucunda meydana gelen lock-out olma durumuna yakalnmazlar. Şifre değişikliği sonrasında SQL Server Servisinin restart edilmesine gerek bulunmaz. Aşağıda belirtilen adımlar pre-reqlerin tamamlanmış olduğu varsayılarak step by step aktarılmıştır. Prerequisetlerle ilgili detaylı bilgilendirmeye  https://technet.microsoft.com/en-us/library/jj128431.aspx#BKMK_gMSA_Req  linkinden erişilebilir. 1-  Active Directory Users and Computers Altında Global Security Group Oluşturma gMSA 'i kullanacağımız sun

Import Active Directory Module in Powershell

Active Directory rolüne sahip olmayan bir workstation üzerinde AD yönetimi için powershell script çalıştırmak istiyorsanız öncelikle Remote Server Administration Tools feature’ini workstation üzerinde kurmalısınız. Kurulumu tamamlandıktan sonra aşağıdaki komut ile öncelikle modüller arasında ActiveDirectory modülünün olup olmadığı kontrol edilir, eğer modüller arasında ActiveDirectory modülü yoksa session bazında Import-Module cmd’letiyle Active Directory commandletleri kullanımımıza açılır. if ( -not ( Get-Module -Name ActiveDirectory -ea Continue )) { Import-Module ActiveDirectory -ea Stop } Umarım faydalı olur.  

Fun With Docker..ELK Stack- ElasticSearch

Herkese Merhaba, Fun with Docker yazı serisine ELK Stack kurulumunu aktaracak, yazı dizisi içerisinde yeni bir yazı dizisiyle devam etmeye karar verdim. Bilmeyenler için ELK, 3 ayrı open source proje olan Elasticsearch, Logstash ve Kibana projelerinin birleşiminden oluşan yine open source olarak kullanıma sunulan ve bakımı Elastic tarafından  yürütülen bir proje. Bu arada ELK Stack ile ilgili tüm detaylara  https://www.elastic.co/elk-stack  linkini kullanarak ulaşabilirsiniz.  Peki biz yazı dizisi sırasında ELK Stack ile neler yapmaya çalışacağız? Docker hostumuz (Windows 10) üzerinde File Beat kurarak, IIS Loglarını toparlayacağız. Topladığımız bu IIS loglarını container üzerinde koşan LogStash'e gönderecek ve LogStash üzerinde yaptığımız konfigürasyonlarla parse operasyonunu tamamlayıp, oluşan anlamlı datayı yine container üzeride koşan ElasticSearch 'e insert edeceğiz.  Insert ettiğimiz tüm bu log datasını ise yine container imajı olarak ayağa kaldırıp