DevOps II
Her şey öncesinde bir gaz ve toz bulutuydu aslında …
DevOps Süreçlerini açıklamadan önce, bu süreçler öncesinde kullanılan TFS kavramının ne olduğu hakkında bilgi sahibi olalım. O zaman buyrun :)
Team Foundation Server, Microsoft’un Yazılım Yaşam Döngüsü aracıdır.Yazılım Yaşam Döngüsü kavramı,kısaca ALM(Application Lifecycle Management)olarak geçmektedir.TFS, takım halinde çalışılan projelerde ekip içerisinde iletişim ve verimi arttırmak, projelerin yönetimini kolaylaştırmak için kullanılan bir Microsoft ürünüdür.
TFS’i , üç ana kategori altında toplayabiliriz.Bunlar;
- Veri Katmanı: Veri depolamak için SQL sunucusu kullanılmaktadır.
- Uygulama Katmanı: TFS Server, Web Servisleri(TFS istemcileri için bir arayüz gibi çalışan servislerdir),Server Object Model(TFS Sunucusu ve SQL sunucusu arasında veri akışını sağlar.)
- Yapım Katmanı: Build Servis(Controller ve Build kısımlarını içermektedir), Build Project Object Model(Build definition tanımları yapıldığında iş akışlarının belirlenmesi durumudur.), Client Object Model(TFS Sunucusu ve Build servis arasındaki veri alışverişini sağlamaktadır.)
TFS Mimari
TFS, Windows Server işletim sunucusu üzerine kurulur. Kurulum işleminden sonra verilerin saklanabilmesi için Windows SQL Server üzerine kayıt altına alınır. Microsoft Internet Information Services üzerinden yayınlanır ve İnternet tarayıcıları aracılığı web arayüzüne erişim sağlanılır.
Microsoft Visual Studio, Eclipse vb. araçlar ile TFS sistemine erişilebilir veya yazılım kaynak kodları TFS ortamına aktarımı sağlanabilir.
Sıra geldi şu sorunun cevabını almaya, TFS anladık peki nedir bu VSTS?
Visual Studio Team Server, yazılım süreçlerinin geliştirilmesi yazılım ekiplerinin daha iyi iletişim kurmasını sağlayan araçlardan oluşan, genişletilebilen ve kullanım ve kullanıcı ihtiyaçlarına göre şekillendirilebilen yazılım geliştirme süreç yönetimi platformudur.
VSTS 4 temel madde üzerinden özetleyebiliriz;
- Servis temelli mimari uygulaması geliştirmeyi kolaylaştırmak(SOA)
- Tüm ekip için daha iyi iletişim ortamının olduğu çalışma ortamı sunmak
- Güvenli bir yazılım geliştirme süreç yönetimi platformu geliştirmek(SDLC),
- Özelleştirilebilir süreç yönetimi sağlamak.
Bu maddeler üzerinden VSTS hakkında genel bilgiye sahip olmuş bulunmaktayız.Aklımıza takılan sorulardan birisi şu olabilir, TFS varken neden VSTS ihtiyaç duyuldu?
Teknolojinin gelişmesi ve projelerin her geçen gün karmaşıklaşması, daha büyük proje ekiplerinin kurulmasına sebebiyet vermektedir.Proje çalışan sayısının artması ile, proje yönetimi ve sürecin daha iyi takip edilmesi gerekmektedir.Bu sürecin yönetimi için de olan ürün yeterli olmadığı için yeni bir ürüne ihtiyaç duyulmuştur.Yeni ürün hedefi(VSTS); genişletilebilir, özelleştirilebilir ve yönetilebilir bir ürün geliştirme platformu sunmaktır.
Yeni ürün olan VSTS’in avantajı, diğer Microsoft ürünleri ile entegre çalışabilmesi ve özelleştirilebilir süreç yönetiminin yanında genişletilebilir ürün yelpazesi sunmasıdır.Yazılım süreç yönetimi için entegre ve ihtiyaçlara uygun bir şekilde özelleştirilebilir ve genişletilebilir bir platform.
Aynı zamanda yeni gelişmeler ile birlikte VSTS ve TFS ‘in isimleri Azure DevOps duyurusu ile değişmiştir. Artık VSTS’e Azure DevOps , TFS ‘ in 2019 sürümüne ise Azure DevOps Server 2019 denilmektedir. Yine de TFS ‘in eski sürümleri hala TFS olarak geçmektedir.
Yazılım Süreç Modeli, SDLC’de belirtilen süreçlerin geliştirilmesinde, hangi sıra veya düzen ile uygulanacağını tanımlayan modellere denir.
SDLC(Software Development Life Cycle ) Nedir?
Özellikle ürün geliştirme işlemleri çeşitli aşamalar içermektedir. Bu aşamaların sistematik ve doğru bir şekilde ilerleyebilmesi için gerekli adımlar bulunmaktadır. Özellikle bir yazılım projesi içerisinde ihtiyaçlar sürekli değişkenlik gösterdiği ve projenin devamlı gelişmesine ihtiyaç olduğu için ,SDLC bir döngü halinde kullanılır. Adından da anlaşılacağı gibi SDLC bir döngüdür.Döngü halinde olma durumu,yazılım geliştiriciler için özellikle büyük yarar sağlamaktadır.Çünkü döngü içerisindeki herhangi bir aşamaya kolayca geri dönme ve tekrardan ilerleme imkanı sağlar. SDLC 5 adımdan oluşmaktadır.Bunlar;
- Planlama
- Analiz
- Tasarım
- Geliştirme
- Test ve Bakım
Software Development Life Cycle yani SDLC diye tanımladığımız yaşam döngüsünün aşamalarını detaylandırılacak olunursa;
Planlama: İstenilen proje en ince ayrıntısına kadar anlaşılmaya çalışılır.Bu aşamada istenilen proje ile ilgili ayrıntılar belirlenir ve bu ayrıntılara göre planlama yapılmaktadır.
Analiz: Planlama aşamasında belirlenen ayrıntılar doğrultusunda yapılan planlamalar ile, bu planlama sonucunda ortaya çıkan veriler değerlendirilir ve projenin geliştirilme aşamasında ihtiyaç duyulacak teknolojiler, gereksinimler belirlenerek bir liste hazırlanmaktadır.Bu listede sistemsel, yazılımsal,çalışan gibi kısımlar bulunmaktadır.
Tasarım: Projenin planlama ve analiz aşamaları belirlendikten sonra, bu aşamalar sonucunda çıkan raporlar dahilinde, sistem tasarlanmaya başlanılmaktadır.Tasarım aşamasında müşterinin ihtiyaçları aynı zamanda taleplerini karşılamak için projenin içerdiği bileşen ve mimari belirleme işlemleri yapılmaktadır.Sistem yapısının anlatıldığı, yazılımın ve mimarinin anlatıldığı fiziksel bir tasarım yapılmaktadır. Bu proje ile ilgili UML Diyagramları ve ER Diyagramları kullanılır.
Geliştirme: Tasarım işlemi tamamlandıktan sonra, geliştirme aşamasına geçilmektedir. Geliştirme aşamasında kod geliştirme, test ve kurulum kısımlarını içerisinde barındırmaktadır.Düzenli olarak projenin test edilmesi, hataları kısa sürede görüp müdahale etmemiz açısından önemli bir aşamadır.Örnek verilecek olunursa; bir binanın sağlam temeller üzerine kurulması ilerideki aşamalarda kat çıkarken çökme riskini en aza indirmektedir. Örnekten yola çıkacak olursak eğer projenin sağlam temeller ile inşa edilirse, sonraki adımlarda probleme istenilen şekilde müdahale etme olanağı sunmaktadır ve temel sağlam olduğu için hata ile karşılaşma olasığı daha azalacaktır.
Test ve Bakım : Projenin geliştirme aşaması sona erdikten sonra, proje müşteriye teslim edilmeden önce test işlemleri yapılmaktadır.Herhangi bir noktada sorun olmaması durumunda proje canlıya alınabilir. Hata olması durumunda ise ihtiyaç ve eksiklikler giderilerek tekrar müşteri onayına sunulmaktadır.Böylece üretilen yazılım ihtiyaca tam olarak hizmet edecektir.
VSTS hakkında genel bilgiye sahip olunduktan sonra, Azure DevOps hizmetlerinin neler olduğunu nasıl kullanıldığı hakkında bilgi sahibi olalım.
Evet şimdi Azure DevOps’u keşfedelim…
Aslında Azure Devops için yukarıdaki görsel açıklayıcı ve tanımlayıcı olmaktadır. Ekip içerisinde her bir kişinin farklı işlerle ilgilenmesi ve koordine bir şekide hareket edilmesi, ortaya çıkacak ürünün takibi geliştirmesi gibi yapıları
Azure Boards: Ekipler arasında planlama, iş takibi ve yönetimi yapabilmek için Agile araçlarını kullanarak kullanıcılara daha hızlı ulaşmamızı sağlamaktadır.
Azure Pipelines:Tüm programlama dilleri, platformların derlenmesi, test edilmesi ve dağıtım kısımlarını barındırmaktadır. GitHub veya başka bir Git sağlayıcısına bağlanarak geliştirme yapmamızı sağlamaktadır.
Azure Repos: Geliştirme yapılan kodların derlenilmesi için sınırsız ve bulutta barındılan özel Git depoları edinmemizi sağlamaktadır.
Aynı zaman da projemizin geliştirilme stratejisi olarak branch geliştirme modeli önemli rol almaktadır.
Bu kısımda Branch’in kullanımına biraz deyinmek istiyorum.
İlk olarak branch modelimizde temel olarak belirlediğimiz nokta ‘origin’ olarak adlandırılan kısımdır. Genel kuralından bir tanesi her bir developer origin kısmına push ve pull işlemini gerçekleştirebilmektedir.
Temel anlamda repo iki ana branch’den meydana gelmektedir.Bu iki branch master ve develop olarak isimlendirilmektedir.Aslında master branch dediğimiz kısım, ana branch olarak belirlediğimiz kısımdır.Buna paralel olarak belirlenen ikinci ana branch ise develop ya da dev diye isimlendirilen branch yapısı olacaktır.
Temel anlamda origin/master branch temel branch yapısı olarak düşünülmekte ve bu branch içerisindeki kodlar her zaman projemizin yayınlanmaya hazır halidir. Bir ikinci branch olan origin/develop ise, geliştirme evresinde olan ve gelecek sürümde yayınlanacak olan projenin son hali ile ilgili kaynak kodları içermektedir.
Develop branch’de bulunan kodun testi yapılmış ise ve düzgün çalışıyor ise , develop branch’den master branch merge edilmelidir. Her güncelleme sonrasında master branch’de bulunan kodun tag’lenmesi durumuna dikkat edilmelidir.
Aynı zamanda farklı branch tipleri de bulunmaktadır.Bunlar; Feature branch,Release branch ve Hotfix’dir. Branch’lerin isimlendirilmesi gereken task’ın amacına göre olmaktadır.
Feature Branch: Gelecek versiyonda ekleme yapılacak olan özelliklerin geliştirildiği branch modelidir.Ayrı bir branch’de yeni özelliklerin tutulmasının avantajı, projenin ilerleyen kısımlarında herhangi bir özelliğin bekleneni vermediğinde ya da ilgili özelliğin kaldırılması istenildiğinde projenin orijinal yapısının bundan etkilenmemiş olmasıdır.
Release Branch : Gelecek olan sürümde yayınlanacak güncellemeleri desteklemek için kullanılan branch modelidir. Bu branch içerisinde ayrıca ufak hataları düzeltme durumları da yer almaktadır.
Hotfix Branch: Release Branch’e benzemesinin yanı sıra , tek farkı canlıda olan projenin kritik hatalarının çözmek amacıyla oluşturulduğu kısımdır.
Azure Test Plans: Kullanıcıların el ile test edip gönderebildikleri kısımdır.
Azure Artifacts: Paket oluşturma,oluşturulan paketlerin saklanılması işlemlerinin yapıldığı kısımdır.
Projelerin büyümesi ekiplerin entegre çalışma durumlarının yaygınlaşması ile beraber, büyük kolaylıklar sunulmaktadır.Hayat kurtaran diye tabir edilen ve çoğu yerde bahsedilen bazı komutların isimlerine değinerek yazıma son vermek istiyorum.
Hayat Kurtaran Komutlar;init, status, add, commit, remote, branch, merge,conflict, remote, push, pull, log’dur.
Bir sonraki yazımızda görüşmek dileğiyle… 🌸
