Birleştirilmiş Pull Request’lerden Sürüm Notları

Sık yayın yapan ekipler kullanıcılarına neyin değiştiğini anlatmak zorundadır ve ham malzeme zaten vardır: başlıkları, açıklamaları ve etiketleri olan birleştirilmiş pull request’ler. Bir GitHub deposuna bağlanan, son sürümden beri birleştirilen pull request’leri toplayan ve geliştiriciler için değil kullanıcılar için yazılmış sürüm notları taslağı hazırlayan bir araç geliştir: yeni, iyileştirilmiş ve düzeltilmiş olarak gruplanmış, şirket içi jargonsuz.

Kapsamı iyi çizilmiş bir entegrasyon projesi: bir erişim jetonu ya da OAuth uygulaması, herkese açık bir API, bir dil modeli ve bir düzenleyici.

Sürüm notu yazmak, genellikle her sürümün sonunda tek bir kişiye kalan sıkıcı bir iştir. Commit mesajları ve pull request başlıkları diğer geliştiriciler için yazılır (“refactor auth middleware”, “fix #482”), bu yüzden olduğu gibi bir değişiklik günlüğüne yapıştırılamaz.

Sonuç olarak birçok küçük ekip hiç not yayınlamaz ya da kullanıcıların anlamadığı notlar yayınlar; kullanıcılar da kendileri için yapılan iyileştirmeleri kaçırır.

• Bir iki haftada bir sürüm çıkaran küçük yazılım ekipleri ve bağımsız geliştiriciler.
• GitHub’da sürüm yayınlayan açık kaynak bakımcıları.
• Değişiklik günlüğünü elle hazırlayan küçük şirketlerdeki ürün yöneticileri.

Birinin bir depoyu bağladığı, bir aralık seçtiği (son etiketten bu yana ya da iki tarih arasında) ve bir taslak aldığı bir web uygulaması. Sunucu birleştirilmiş pull request’leri GitHub API’si üzerinden alır, her birinin başlığını, açıklamasını ve etiketlerini tutar ve bunları net talimatlarla bir dil modeline gönderir: kullanıcılar için yaz, türe göre grupla, ilgili değişiklikleri birleştir, yalnızca şirket içi işleri dışarıda bırak ve emin olunmayan her şeyi işaretle.

Taslak, düzenlenip kopyalanmak ya da bir GitHub sürümünün gövdesi olarak yayınlanmak üzere bir Markdown düzenleyicide açılır. Her satır geldiği pull request’lere bağlanır, böylece kontrol etmek hızlı olur.