Bu yıl (2018) şubat civarı internal kodları gitlab üzerinde tutmaya başladık. Büyük ölçüde karar vermemizi Gitlab’ın CI ve CD için sağladığı özellikler etkili oldu. Böylelikle sağlam bir yazılım geliştirme bandı oluşturup test, build, stage, production-test ve nihayet production bölümlerini analitik bir yapıya kavuşturmayı başardık. Şimdilik memnunuz.
Özellikle stage ortamında production testleri patladığında hangi alanda ve hangi sürümde olduğunu bilmemiz ve otomatik issue oluşturmak gibi bir fantazimiz var. Bu aşamada da bir versiyonlamaya ihtiyaç duyduk.
Tabi production versiyonundan bağımsız sürekli çalışan uygulama ile muhatap olacağımızdan sırf stage ortamı için developer takımının kullandığı bir versiyonlama lazım oldu.
Bu versiyonlamayı git üzerinden şöyle çıkarttık.
[SON COMMIT].[BOLUM ADI].[COMMIT SAYISI]
çıktısı şu şekilde oluyor.
65a216a.stage.699
Bu değeri aşağıdak komut ile kazabiliyorsunuz.
echo $(git describe --always --long --dirty=.stage).$(git rev-list HEAD | wc -l | awk '{print $1}')
Şimdi bu versiyonlamadan ne anlıyoruz?
Öncelikle “65a216a” değeri ürünün son commit’i olduğunu biliyoruz. Production Test’ler fail’e düşerse otomatik olarak [65a216a] tag’ı ile issue açılıyor ve fix geçilirken de o commit’den sonraki fix olduğunu developer biliyor.
“stage” değeri CI ortamında hangi bölüm için build edildiğini tutuyor. Yani canlıya çıkılmamış unit testler başarılı şekilde çalışmış. Pre-prod ortamı için test edilmeyi beklendiği anlaşılıyor.
“699” ise ürünün tüm commitlerini sayıyor bir çeşit build number gibi.
Bunu production’a çıtığımızda ki semver’e de bağlamak istiyorum aslında örneğin
v1.2.0.0-65a216a
gibi. Semver’i orada Tag’lar üzerinden yönetiyoruz. Henüz karar vermedim ama build numarasının son commit olması anlamlı (faydasını henüz keşfetmedim)
Yukarıdaki çıktıyı oluşturan komut ise aşağıdaki gibi.
echo $(git describe --tags --long)-$(git describe --always --long)
Başka yaklaşımları da merak ediyorum aslında. Tavsiye olursa sevinirim.