Devops, yazılım değişikliklerini hızlı ve güvenli bir şekilde yapma amacı taşıyan yaklaşım ve uygulamalardır.

Hızlı ve Güvenli — The Gurkha

“Devops yapmak”, “Agile olmak”, bunlar el ele tutuşup hep birlikte karşı tarafa atlayabileceğimiz bir şeyler gibi anlatılabilir, bu şekilde anlaşılabilir. Halbuki bunlar birer süreçtir ve “top yekûn” geçişten önce yapabileceğimiz seçimler, hayata geçirebileceğimiz uygulamalar vardır.

Devops hem taleplerinin hızla gerçekleştirilmesini bekleyen “tez canlı” Developer’ların, hem de her günü sistemlerin güvenli ve kesintisiz çalışması stresi ile geçen “ihtiyatlı” sistemcilerin endişelerini ortadan kaldıracak, onların uyum içinde beraber çalışmasını sağlayacak uygulamalardır diyebiliriz.


Bu sözü, yazılım işi için “Teknik borcu kapatamıyorsan, en azından daha fazla borçlanma” diye çevirebiliriz.

Zira, o an için aslında ‘yanlış olduğunu bildiğimiz’ fakat ‘daha az zaman almasının’ cazibesine kapıldığımız bu seçimler, var olan sorunu derinleştiriyor ve eninde sonunda zamanı gelince birinin yapmaya mecbur kaldığı düzeltmeyi/iyileştirmeyi (aslında bir ‘Refactor’ü ) zorlaştırıyor.

Benim tecrübe ettiğim bazı ‘kazmayı bırakma anları’ şunlar;

  • Bu class’da zaten hiç yazılmamış diyerek, birim test’i yazmayı es geçmek yerine, artık her değişiklikte ve yeni geliştirimde birim testlerini yazmak.
  • İhtiyacımız olduğunda, düşük performanslı veya güvensiz, “önceden yazılmış hazır” bir metodu o şekli ile kullanmaya devam etmek yerine, yenisini yazıp, üstüne önceki çağırımları da iyileştirmek.
  • 2 yaşına girmiş 20+ açık Sonarqube Issue’ların (Statik kod taraması sonucunda çıkan bulguların) hepsinin birlikte planlanması beklemeyi bırakıp, artık yeni Issue’ları aynı Sprint’te kapatmaya başlamak.

Sizin de eğer varsa kazmayı bıraktığınız anlarınızı burada paylaşırsanız, minnettar olurum.

Esen Kalın.


Creating BUGs in the AzureDevops Backlog using Sonarqube Issues

The visibility of technical debt is a very important factor in managing the quality of software. Sonarqube is one of the most widely used code scanning tools. Therefore, creating a Sonarqube issue as a BUG in the team’s backlog is an almost indispensable need to resolve technical debt in the code.

In this article, I will explain how Sonarqube Issues can be automatically created as BUG in Azure Devops Backlog using Sonarqube Web API, Microsoft Azure Logic App, Azure Devops Pipeline and Azure Devops API.

As good news, we will be able to do this without the need to create…


Daha iyi bir çevrimiçi sunum tecrübesi için işinize yarayacağını düşündüğüm ipuçlarını paylaşmak isterim.


Yazılım geliştirmede isimlendirme işini ne küçümsemek ne de abartmak doğrudur. Önemli olan nokta isimlendirmedeki şansımızı, bizden sonraki yazılımcıya mümkün olan en doğru mesajı verecek şekilde ustaca kullanmaktır.

İsimlendirmelerde dokunduğu yeri en iyi anlatan, en sade tercihi yapmanız gerekir.

Kaliteli bir uygulamanın bakımı kolaydır. Uygun isimlendirme tercihleri kodun bakımına dolayısıyla kalitesine olumlu katkı sunar. İsimlendirme konusunun önemi buradan gelmektedir. Şimdi, daha önce okuduğum kodlarda karşılaştığım bazı geliştirilebilir isimlendirme örneklerini aktarmaya çalışacağım.

Olumsuz İfade Kullanmak ❌

İnsan beyni olumlu bir ifadeyi daha rahat çözer. O nedenle ToplamAgirligaDaraDahilEdilmeyecekMi şeklinde bir ifadeyi anlamakta biraz zorlanabiliriz. Bunun yerine üzerinde biraz düşünüp DaraHaricMi diye bir tercihte bulunabiliriz.

Yapılmamalı yerine EngellensinMi…


Konsantre olmuş şekilde çalışan Metrobot ekibi
Konsantre olmuş şekilde çalışan Metrobot ekibi
İzmir Hackathon — Metrobot ekibi.

Salgın patlamadan hemen önce yapılan İzmir Hackathon’da yarışma fırsatım oldu. Hayatımda yaşadığım en güzel tecrübelerden birisiydi. Bir yazılımcının hayatında en az bir kere bir Hackathon’a katılmasını, bu havayı koklayıp bu keyfi almasını umuyorum.

Bu yazıda bizi Hackathon’da başarıya götürdüğünü düşündüğüm önemli noktaları kaleme almaya çalıştım.

Maceraya Evet Deyin!


Biztalk gecelerine akarken …

Bazen kendinizi bir toplantının ortasında “mis gibi kod yazarken çağırdılar, ne işim var benim burada …” diye düşünürken buluyor musunuz? Evet diyorsanız devam edelim.

Bugün hem bunun gibi sevimsiz olanları, hem de yükselip acayip iyi hissettiğim bazı anları paylaşmak istiyorum.

Şunları duyduğumda oradan ışınlanmak istiyorum

Daha okunmamış (en az 3 haneli olmalı) X adet e-postam var. (Bu sık saklandığımız gölgelerden birisidir. Gereksiz e-postaları filtrelemek ve kalanlara sahip çıkmak bizim elimizde.)

”Çok meşgulüm” demenin başka biri yolu; “Bunu bana e-posta atar mısın?” (Vale hizmetimiz yok demek geliyor içimden :) Aslında bir konuyu unutmamak için e-postaya ihtiyacım olsaydı bunu atmasını başkasından beklemezdim. Kendim yapardım.)

Bunu test etmeye…


Uygulamamızın derlenmesi ve istenilen işi bir şekilde yapması üniversite dönem ödevimiz için yeterli olabilir. Fakat iş kurumsal bir yazılım üretmeye gelince bundan fazlası gerekir.

Yazılım geliştirme faaliyeti sırasında aldığımız bazı kararlar yazılımın kalitesine olumlu katkı sağlarken, kimisi de buna engel olur.

Yazılım kalitesi dediğimiz şey aslında hangi niteliklerdir, bizim hangi faaliyetlerimiz bu niteliklere nasıl etki eder, işte bu yazıda bunlardan bahsetmek istiyorum.

Bir yazılım ondan istenen işi doğru olarak yapacak işlevlere sahip olmalıdır. Yani isteneni yapmalıdır. Bununla birlikte …

🔒KALİTELİ YAZILIM GÜVENLİDİR.

🚫Yetkim olmayan işlemi çalıştıramam.

🚫Yetkim olmayan bilgiyi göremem.

🛡️Bilgi veya iletişimim ifşa olmaz.

🛡️Uygulama ve sistem zayıflık (zafiyet) içermez.

Kaçınalım❗

❌ “everyone”…


Dedalus’un oğlu “Ikarus”un Yunan mitolojisinde bal mumundan tutturulmuş yapay kanatlarıyla hapsedildiği Girit adasından kaçarken uçuşun cazibesine kapılıp çok yükseldiği ve güneşe fazla yaklaşıp bal mumu bağlayıcıların erimesi sonucu Akdeniz'e düşüp öldüğü anlatılır.

Ikarus sendromu ise, bir işin ustasının, tecrübesinin verdiği rahatlık ve öz güven ile temel kontrol ve kuralları göz ardı etmeye başlayıp, basit hatalar yapması olarak tanımlanabilir. Pilotlar ve motosiklet sürücüleri için bu durumun sonuçları çok üzücü olabilir.


Bir BUG’ı hiç yaşanmamış saymak ile tekrar edilemediği için kapatmak arasında neredeyse fark yoktur.

Senin bilgisayarında çalışıyor çünkü …

Senin kullanıcın “admin” olarak tanımlı, her sunucuya girer-çıkar yazar-silersin, kullanıcının standart tanımı belki “read-only” bile değil.

Sen uygulamaya tüm yamaları yüklenmiş Windows 10'dan, kullanıcı Windows 2008 R2 TS üzerinden erişiyor.

Sen hatayı o “bug” kaydına sıra geldiğinde, sana uygun zamanda tekrar etmeye çalışıyorsun, hata ise sistemi kilitleyen başka bir sorgunun çalıştığı anlarda meydana geliyor.

Sen Chrome kullanıyorsun, hemen derleyip sayfayı ekrana basıyor, kullanıcıda artık “sistem destek” zamanında ne kurdu ve hangi versiyonda bıraktıysa o var.

Sen bilgisayarını sunucuyla aynı switch’e bağlayabilecek kadar sistem odasına yakınsın, kullanıcın Senegal Telekom — VPN — Türkiye artık nereden kaç hop ile geliyorsa o kadar uzakta.

Yani aslında, sen derleyip, “Check-In” yaptığın şeyde hata ararken, kullanıcı bunu mümkün kılan birçok bileşene bağlı olan, ekranında o anda çalışması gereken uygulamaya yansıyan problemden bahsediyor.

Serkan Apul

Software Tech. Lead at Bimar (Arkas Holding) https://www.linkedin.com/in/serkanapul/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store