Derleme Betiği ve Derleme Sunucusunun Sorumlulukları

Yapı Komut Dosyası ve Yapı Sunucusu'nun sorumlulukları hakkında bazı açıklamalara ihtiyacım var.

Net hakkında sürekli entegrasyon ve derlemeler hakkında birkaç makale okudum. Dahil olmak üzere

Danışmanımla yazılımımızın oluşturma süreci hakkında bir görüşme yaptım. Çok tecrübeli olduğu için ifadelerine güveniyorum, ama karışıklık içinde kaldım.

Anladığım kadarıyla, araştırmamdan (ve lütfen beni düzeltin, çünkü sorduğum şey budur) ideal aşağıdaki gibi olmalıdır:

her projenin derleme betiği vardır
bu komut dosyası projeyi derliyor
bu komut dosyası bağımlılıkların daha önce oluşturulmasını sağlar

Bağımlılıklar başka bir proje olabileceğinden, kendi derleme komutlarıyla ağaç benzeri bir hiyerarşi tahakkuk eder. Tüm projeleri ve uygulamaları oluşturan bir üst derleme betiği olabilir.

Ancak Yapı Sunucusunun sorumlulukları:

depoyu kontrol et
yapıyı tetikle
tetik testleri ve diğer KG araçları
eseri kullanılabilir yapmak

Bu, manuel olarak, her gece veya depo değiştiğinde tetiklenebilir

Danışmanımın amaçları, anladığım kadarıyla, bir derleme komut dosyasının esnek olmayan ve sürdürülemeyen bir yol olduğudur (Eski kod tabanımız için bir tane oluşturmanın çok uzun süreceği gerçeğinin yanı sıra). Ayrıca Build Server bağımlılıkları korumalıdır, örneğin yeni başarısızlıklar oluştururken eski bağımlılıkları kullanmak için. Özellikle Antsomut konu olduğu için, kod tabanında kullanılan her türlü farklı teknolojiyi inşa edemez ve bağımlılıkları koruyamaz.

Lütfen hedefleri açıklayabilir ve sorumlulukları netleştirebilir misiniz?

version-control continuous-integration builds

— Angelo.Hannes
kaynak

Bu iyi bir soru olduğu ve cevaplanacağı kadar (daha sonra zamanım olduğunda ve henüz cevaplanmadığında): gerçekten geri dönmeli ve danışmanınızdan açıklama almalısınız. Performansınızı değerlendirecek biriyle görüştükten sonra kafanız karışmak bir felaket tarifi ve sizinle yeterince iletişim kurmadıklarının (veya aktif olarak dinlemediğinizin, ancak durum böyle görünmediğinin) bir göstergesidir. buraya).

— Steven Evers

@ Angelo.Hannes Bence tüm önemli noktaları vurdun. Ne hakkında kafanız karıştığını daha net açıklayabilir misiniz?

— M. Dudley

@SteveEvers Bu konuyla ilgili bazı tanıtımları okuduğum gibi, önce bu konudaki bilgimi genişletmek istedim. Bu konuyu kesinlikle tekrar ele alacağım. Bu yüzden cevaplarınızı gerçekten takdir ediyorum.

— Angelo.Hannes

@ M.Dudley Dediğim gibi, hangi sorumlulukların nereye gittiğinden emin değilim. Ve tüm yazılım için bir yapı komut dosyasının doğru yol olup olmadığı.

— Angelo.Hannes

Bunlar dikeydir:

Script kurmak taze kontrol aşımı kaynak ağacındaki çağrılması sırasında, gerekli hedefleri ve bağımlılıkları tam bir yapı verir, o mekanizmadır. Bir makefile veya MSBuild, Ant, Maven veya Scons'un uygun bir çağrılması varsa, 'hepsini yap' olabilir. Karmaşık bir bağımlılık hiyerarşisi veya ilgili projeler varsa, 'komut dosyası oluşturma', her birini sırayla çağıran ve devam ederken başarıyı kontrol eden üst düzey bir dosya olabilir.

Derleme betiği, pek çok kişinin yalnızca bir betiğidir - ödeme, derleme, test, paket - ancak komut satırı parametreleri tarafından kontrol edilen hepsi bir arada bir mekanizmaya sahip olabilirsiniz - ortamınıza bağlıdır.

Yapı sunucusu veya daha doğrusu sürekli entegrasyon sunucusu , -> build -> test -> package -> stage -> dağıtım hattının planlanması / tetiklenmesi, izlenmesi ve raporlanmasından sorumlu otomasyon mekanizmasıdır. Elinizde daha sofistike bir şey yoksa cron / Görev Zamanlayıcı'yı kullanabilirsiniz, ancak Jenkins, Cruise Control, TeamCity vb.Gibi birçok mükemmel araç var.

Bir yapı çağırabileceği önemlidir olmadan bunun / çevrimdışı / ulaşılamaz / aksi-kullanılamaz, bu nedenle mantık inşa / testi yaptırmak / olmaya bitti ne olursa olsun ihtiyaçlar dışında meşgul olması durumunda, CI sunucusunu kullanarak CI sistemi, ancak onun tarafından çağrılabilir, şube / yapı türü / sürüm / mimari vb.

— JBRWilkinson
kaynak