Geliştiriciler için Çevik Uygulama Geliştirme Süreçleri ve Araçları — I
Merhabalar herkese , bilgi işlem operasyonlarının giderek hız kazanması ve yazılım süreçlerine dahil edilmesi ile birlikte “ Task takibi , sürekli entegrasyon , statik testler , kabul testleri vb… ” bir çok kavram biz yazılım geliştiricilerin gündelik döngüsüne dahil oldu. Bu konuda bir çok metodoloji , bir çok yaklaşım olmakla birlikte “Çevik Yazılım Geliştirme Metodolojisi” kavramı en çok konuşulan ve uygulanan yaklaşım olarak kullanılıyor.
Öncelikle genel altyapıdan ve bizim geliştirmekte olduğumuz projelerdeki Çevik Yazılım Geliştirme araçları hakkında ön bilgi sahibi olmanız adına aşağıda bulunan linkler üzerinden daha önce yazmış olduğum 2 adet yazıyı inceleyebilirsiniz.
Versiyon Kontrolü ,Git Komutları ve Branch Kavramı
Günümüzde yazılım geliştirme faaliyetleri arasında en sık adını duyacağınız konulardan birisi Versiyon Kontrolü ve Git olacaktır. Versiyon kontrolü bir dosya veya bir küme dosyadaki değişiklikleri takip edebilmek için uygulanabilecek bir yöntem olarak tanımlabilir. Git gibi sistemleri ise tüm bu değişikliklerin tarihçesini ve içeriğini bizim için takip ederek kayıt altına almamızı sağlayan veritabanları olarak düşünebiliriz.
Versiyon kontrolü kullanmak “uyumlu ekip çalışması , versiyonların düzgün takip edilmesi, önceki versiyonlara geri dönebilme, değişikliklerin nedenini anlama, yedekleme“ gibi kavramlar açısından biz yazılım geliştiriciler için önemli bir yerdedir.
Biz uygulamalarımızı geliştirirken versiyon kontrol sistemi olarak git tabanlı çalışan Atlassian ürün ailesinde içinde yer alan BITBUCKET ‘ ın bulut üzerinden SAAS olarak hizmet veren versiyonunu kullanıyoruz.
Git kullanımı ile ilgili bize göre en yalın ve en güzel anlatıma sahip olan sayfaya aşağıdaki link üzerinden ulaşabilirsiniz.
Branching kavramı ile bir uygulama üzerinde tüm ekip çalışanlarının aynı anda geliştirme yapma ve oluşabilecek tüm sorunların önüne geçmek için kullanabileceğimiz bir araç ve yaklaşımdan bahsetmiş oluyoruz. Branching ile farklı bağlamları birbirinde kolayca izole ederek her birini kolayca ve ayrı ayrı yönetebilirsiniz. Yani kısa bir anlatım ile takım arkadaşınız aynı uygulama için bir feature geliştirken , siz bir bug ile uğraşabilir yada başka bir feature geliştirebilirsiniz. Her geliştirici uygulama kodu üzerinde yapmak istediği değişikliklere göre farklı dallarda çalışabilir ve bu geliştirmeler birbirini etkilemeden uygulamanın son haline yansıtılabilir.
Git branch kavramını anlamak ve bunun üzerine kullanılan birkaç yaklaşımı öğrenmek adına aşağıdaki yazıyı takip edebilirsiniz.
Task Takibi ve Kod Geliştirme Yaklaşımı
Geliştirdiğimiz uygulamalar içinde task takibi olarak yine bir Atlassian ailesi üyesi olan JIRA ürününü kullanıyoruz. Jira kurulumları ve entegrasyonları ile ilgili genel bilgiyi sayfa başında verdiğim linkler üzerinden inceleyebilirsiniz.
Jira üzerinden atanan task,story vb.. mail yolu üzerinden bildirim olarak geliştiriciye ulaşır. Mail üzerindeki link yolu ile Jira üzerindeki issue’ lara ulaşılır.
Geliştirici açılan ekran üzerinden gerekli düzenlemeleri yapıp status durumunu “selected for development” yada “in progress” olarak seçerek , sağ tarafta bulunan development sekmesi üzerinden “create branch” ile yeni bir branch oluşturma isteği belirtir. Bu kısım ile birlikte Jira ile entegre olarak çalışmasını sağladığımız Bitbucket uygulamasına geçerek kalan işlemlerimize devam ediyoruz.
Açılan ekran üzerinde bu açılan branch için “feature,bugfix, hotfix vb.” durumu belirtilir. Jira üzerinde bulunan issue takip numarası bu branch ile otomatik olarak ilişkilendirilecektir.
Bitbucket branches sekmesi içinde Jira üzerinden açılan feature branch takip edilebilmektedir.
Visual Studio üzerinde Team Explorer alanından branches alanı seçilerek “remotes/origin” üzerinden yeni açılan branch ismi üzerinde sağ tıklama ile ulaştığımız “New Local Branch From..” kısmı ile aynı branchi lokalde oluşturma işlemi gerçekleştirilir.
Branch isimlendirme işlemleri tamamlandıktan sonra “Create Branch” buttonu ile aynı branch reposunu lokalde oluşturma işlemi başlatılır.
İşlem bittikten sonra lokalimizde çalışmak üzere yeni bir branch oluşturulmuş olmaktadır.
İstenilen değişikliği belirtilen koşullara göre gerçekleştiriyoruz. Sonrasında “Changes” sekmesine tıklayarak gerekli değişiklikleri ana repository’ e yansıtmak adına gerekli işlemleri başlatıyoruz.
Gerekli değişiklikleri takip edebilmek adına ilgili değişiklikler için bir yorum yazarak buradaki işlemimizi tamamlamış oluyoruz.
Burada “Ongoing Commits” alanında yaptığımız değişiklikleri verdiğimiz açıklamalar ile birlikte görebiliriz. Değişiklikleri ana kaynak kod kontrol sistemimize göndermermeden ( Push Commit ) önce aynı branch üzerinde çalışan başka bir ekip arkadaşımızın olabilmesi durumu için “Incomming Commits ” alanından bir kere “Fetch” yapılması ileride bir çakışma olmaması adına bir önlem olacaktır. Bu işlemleri gözden geçirdikten sonra ilgili değişikliklerimizi göndermek adına “Push” yapmamız gerekecektir.
Visual studio üzerinden yapılan işlemi Bitbucket tarafında “Commits” alanından takip edebilmekteyiz. Burada eğer bir sürekli entegrasyon aracımız var ise (BAMBOO, Jenkins, Azure Pipelines vb…) ve Bitbucket ile entegre şekilde ayarlandı ise “Build” alanında kodumuzun derlenme ve yayına alınma işlemlerini takip edebiliriz. Bu kısımda BAMBOO kullanarak gerekli işlemlerimizi süreçlerimize dahil ettik. BAMBOO kurulumu ile ilgili yazının içinde geçen kurulum ve entegrasyon yazılarından faydalanabilirsiniz.
Kod Derleme ve Yayınlama
Yukarıda bahsettiğimiz üzere geliştirdiğimiz kodların uygun şekilde derlenerek yayınlanması aşamaları için “Sürekli Entegrasyon” kavramından yola çıkarak bir çok araç ve metodolijen faydalanmaktayız.
Geliştirmekte olduğumuz kodların yayınlanma sürecini 3 yardımcı araç tarafından kontrol etmekteyiz. Kod deposu olarak yukarıda bahsettiğimiz üzere “BITBUCKET Cloud” , derleme aracı olarak BAMBOO Server ve statik kod analizi aracı olarak SONARQUBE Server kullanmaktayız. Bitbucket üzerinde yazmış olduğumuz bir Webhook aracılığı ile tüm commit push istekleri Bamboo sunucusunda bulunan planı kullanarak derlenme ve kontrolden geçme işlemini sağlamaktadır.
Projelerimiz ilk olarak oluşturulmaya başladığında standart olarak takım lideri tarafından Bitbucket Coud üzerinde projenin altyapısını sağlayan “master” branch oluşturulur ,bu kodu bamboo sunucusunda derlerken bir kez statik kod analizinden geçirerek , test uygulaması makinasında yayına alınır. Derlenirken kontrolden geçen bu kod alt yapısı için bir “development“ branch açılarak geliştiricilerin bu branch üzerinden gerekli düzenlemeleri yapmaları istenmektedir. Geliştiriciler bir önceki başlıkta kısaca bahsettiğimiz üzere gerekli adımları yaparak kodlarını visual studio üzerinden push commit ile ya da git bash üzerinden “git push -u origin development” komutu ile ana repoya gönderirler.Commit Push yapılması ile birlikte düzenlemiş olduğumuz “Bitbucket Webhook” , Bamboo sunucusuna bir build işleminin gerçekleşmesi gerektiğini bildirmektedir. Bu işlem gerçekleştikten sonra Bamboo sunucusu adımlarını belirlediğimiz ve kurguladığımız planı çalıştırmaktadır. Plan belirlenen aşamaları başarılı şekilde tamamladıktan sonra “Artifact” olarak adlandırılan bir build çıktısı üretmektedir. Üretilen çıktı Bamboo sunucusu tarafından bir shell komutu aracılığı ile uygulamanın geliştiriciler tarafından kontrol ve test etmek amacı ile kullanılan dev sunucusunda bulunan IIS üzerinde uygulamanın çıktısını yayınlayarak sürekli entegrasyon adımını gerçekleştirmiş olmaktadır. Aşağıdaki resimlerden Bamboo ,Sonarqube ve uygulama test sunucusundaki kısımları takip edebilmektesiniz.
Geliştiriciler üzerindeki taskları tamamladıkça ve bitirdikçe yapılan değişikliklerin development branch üzerine alınabilmesi için bir PR (pull request) isteği gönderirler. Bu işlemi bitbucket üzerinde bulunan Pull Request sekmesi üzerinden başlatırlar. Bu işlemi yaparken yapmış olduğu tüm commitler ilgili isteğin içinde gözükmektedir ve bu isteği onaylayacak olan takım liderleri Reviewers alanında default olarak gelmektedir.
PR oluşturulduktan sonra bu işlem , onay verecek takım liderlerine mail yolu ile bildirim olarak gönderilir. Bu işlem için reviewers kısmında belirlenen kişiler gerekli değişiklikleri kontrol eder , bu isteği onaylayarak (Approve) gerekli merge işlemini yaparlar. Bu merge işleminin sonucu bildirim maili ile projedeki geliştiricilere iletilir.
Artık Commits kısmına baktığımızda ilgili merge işleminin yapıldığını görmekteyiz.
Sürekli entegrasyon ve kodun development branchine aktarımını gerçekleştirdikten sonra yapılan değişikliklerin müşteriye yansıtılmasından önce test uzmanları ve proje yöneticileri tarafından gözden geçirilmiş olması gerekmektedir. Bunun için bamboo sunucusu üzerinde günlük olarak çalışacak bir plan daha kurguladık. Bu kurgunun bize faydaları hem uygulamanın release olabilecek sürümlerinin versiyonlanması ve master branch’inin her zaman yayına alınabilecek bir versiyonda kalmasını sağlamak üzere olduğunu söyleyebiliriz.
İkinci planımız düzenli şekilde her sabah belirlediğimiz bir saat içinde elimizdeki master branchi ( hep son kararlı sürüm master branch olduğundan dolayı ) uygulama test sunucusuna yayınlamak üzere kurgulanmıştır. Bu işlem gerçekleştikten sonra Bamboo üzerindeki planı incelediğimizde tüm bu işleme bağlı , commitleri, bu işlem sonucunda oluşan artifact’i , bu işleme bağlı JIRA taskını görebilmekteyiz.
Bu geliştirme sürecinde yapılan işlemlerin hepsini gerek proje yöneticilerine gerek ise müşterimize raporlayabilmek adına yazımızın başında referansta bulunduğumuz yazılara göre entegre ettiğimiz JIRA-BITBUCKET-BAMBOO kurgu sayesinde jira üzerinden takip edebiliriz. Aşağıdaki resim üzerinde jira taraında açılan task kaydu üzerinde tüm sürecimizi takip edebilir ve istenilen detaylara ulaşabiliriz.
Sonuç :
Bu yazımız ile birlikte çevik yazılım geliştirme metodolojilerine yaklaşımlarımızı ve kullandığımız araçları kısaca da olsa açıklamaya çalıştık.
Bir sonraki yazımızda yazılım geliştirme süreçlerinde ne gibi test yaklaşımlarını kullandığımızı ve test süreçlerini nasıl otomatize ettiğimiz hakkında kısa bir yazı ile karşınızda olmayı planlıyoruz.
