"Derleme Sunucusu" nun amacı nedir? [kapalı]

Çok büyük kuruluşlar için çalışmadım ve "Derleme Sunucusu" olan bir şirkette hiç çalışmadım.

Amaçları ne? Geliştiriciler projeyi neden yerel makinelerinde oluşturmuyorlar yoksa onlar mı? Bazı projeler, makul bir sürede inşa etmek için daha güçlü makinelere ihtiyaç duyulacak kadar büyük mü?

Bir Derleme Sunucusunun yararlı olduğunu gördüğüm tek yer, sürekli olarak depoya adanmış olanı inşa eden derleme sunucusuyla sürekli entegrasyon içindir. Yeterince büyük projelerde çalışmadım mı?

Birisi lütfen beni aydınlatın: Bir yapı sunucusunun amacı nedir?

Verilen sebep aslında çok büyük bir fayda. QA'ya giden derlemeler, yalnızca depodan derlenen bir sistemden gelmelidir. Bu şekilde derleme paketleri yeniden üretilebilir ve izlenebilir. Geliştiriciler, kendi testleri dışında herhangi bir şey için manuel olarak kod oluşturmak tehlikelidir. Öğelerin teslim edilmemesi, başkalarının değişiklikleriyle güncelliğini yitirmesi vb. Riskleri çok fazla.

Joel Spolsky bu konuda.

Derleme sunucuları birkaç nedenden dolayı önemlidir.

• Çevreyi izole ediyorlar Yerel Code Monkey geliştiricisi sizin makinenizde derlenmediğinde " Benim makinemde derleniyor" diyor . Bu, senkronizasyon dışı check-in'ler anlamına gelebilir veya bağımlı bir kitaplığın eksik olduğu anlamına gelebilir. Jar cehennemi .dll cehennemi kadar kötü değildir; Her iki durumda da, bir derleme sunucusu kullanmak, derlemelerinizin gizemli bir şekilde başarısız olmayacağına veya yanlışlıkla yanlış kitaplıkları paketlemeyeceğine dair ucuz bir sigortadır.

• Derlemelerle ilişkili görevlere odaklanırlar. Buna, derleme etiketinin güncellenmesi, herhangi bir dağıtım paketinin oluşturulması, otomatik testlerin çalıştırılması, derleme raporlarının oluşturulması ve dağıtılması dahildir. Otomasyon anahtardır.

• Gelişimi koordine ederler (dağıtılmış). Standart durum, birden fazla geliştiricinin aynı kod tabanı üzerinde çalıştığı durumdur. Sürüm kontrol sistemi, bu tür dağıtılmış geliştirmenin kalbidir, ancak araca bağlı olarak, geliştiriciler birbirlerinin kodlarıyla fazla etkileşime girmeyebilir. Geliştiricileri kötü derlemeleri riske atmaya veya kodu aşırı agresif bir şekilde birleştirme konusunda endişelenmeye zorlamak yerine, otomatik yapının uygun kodu görebileceği ve derleme yapılarını öngörülebilir bir şekilde işleyebileceği derleme sürecini tasarlayın. Bu şekilde, bir geliştirici, yeni bir dosya bağımlılığını kontrol etmemek gibi bir sorunla ilgili bir şey yaptığında, hızlı bir şekilde bilgilendirilebilir. Bunu aşamalı bir alanda yapmak, geliştiricilerin yerel yapılarını bozacak kodu çekmemeleri için oluşturulan kodu işaretlemenize izin verir. PVCS, promosyon grupları fikrini kullanarak bunu oldukça iyi yaptı. Clearcase, etiketleri kullanarak da bunu yapabilir, ancak birçok mağazanın sağladığından daha fazla süreç yönetimi gerektirir.

Amaçları ne?
Geliştirici makinelerinin yükünü alın, derlemeler için kararlı, yeniden üretilebilir bir ortam sağlayın.

Geliştiriciler projeyi neden yerel makinelerinde oluşturmuyorlar ya da değiller?
Çünkü karmaşık yazılımlarda, sadece "derlenirken" şaşırtıcı bir şekilde birçok şey ters gidebilir. gerçekten karşılaştığım sorunlar:

• farklı türlerde eksik bağımlılık kontrolleri, ikili dosyaların güncellenmemesine neden olur.
• Sessizce başarısız olan komutları yayınlayın, günlükteki hata mesajı göz ardı edildi.
• Henüz kaynak kontrolünü taahhüt etmemiş yerel kaynakları içeren derleyin (neyse ki, henüz "lanet olası müşteriler" mesaj kutuları yok ..).
• Başka bir klasörden derleyerek yukarıdaki sorunu önlemeye çalışırken, bazı dosyalar yanlış klasörden seçildi.
• İkili dosyaların toplandığı hedef klasör, sürüme dahil edilmemesi gereken ek eski geliştirici dosyaları içerir

Tüm genel yayınlar, kaynak kontrolünden boş bir klasöre alma ile başladığından beri inanılmaz bir kararlılık artışına sahibiz. Daha önce, "Joe bana yeni bir DLL verdiğinde ortadan kaybolan" birçok "komik sorun" vardı.

Bazı projeler, makul bir sürede inşa etmek için daha güçlü makinelere ihtiyaç duyulacak kadar büyük mü?

"Makul" nedir? Yerel makinemde toplu derleme çalıştırırsam, yapamayacağım birçok şey var. Geliştiricilere derlemelerin tamamlanması için ödeme yapmak yerine, zaten gerçek bir yapı makinesi satın alması için BT'ye ödeme yapın.

Yeterince büyük projelerde çalışmadım mı?

Boyut kesinlikle bir faktördür, ancak tek faktör değildir.

Yapı sunucusu, Sürekli Entegrasyon sunucusu için ayrı bir kavramdır. CI sunucusu, değişiklikler yapıldığında projelerinizi oluşturmak için mevcuttur. Buna karşılık, temiz bir ortamda projeyi (genellikle etiketli bir revizyona karşı bir sürüm) oluşturmak için bir Yapı sunucusu mevcuttur. Hiçbir geliştirici hacklemesinin, ince ayarının, onaylanmamış yapılandırma / yapı sürümünün veya taahhüt edilmemiş kodun yayımlanan koda girmemesini sağlar.

Oluşturma sunucusu, iade edildiğinde herkesin kodunu oluşturmak için kullanılır. Kodunuz yerel olarak derlenebilir, ancak büyük olasılıkla diğer herkes tarafından yapılan tüm değişiklikleri her zaman almayacaksınız.

Daha önce söylenenleri eklemek için:

Eski bir meslektaşım Microsoft Office ekibinde çalıştı ve bana tam bir yapının bazen 9 saat sürdüğünü söyledi. Bunu SİZİN makinenizde yapmak berbat olurdu, değil mi?

Derlemelerin ve testlerin çalıştığından ve yapılara bağlı olmadığından emin olmak için önceki sürümlerin yapıtlarından (ve yapılandırma değişikliklerinden) arınmış "temiz" bir ortama sahip olmak gerekir. İzole etmenin etkili bir yolu, ayrı bir yapı sunucusu oluşturmaktır.

Kararlılık, izlenebilirlik ve tekrarlanabilirlik açısından şimdiye kadarki cevaplara katılıyorum. (Bir sürü 'it's, değil mi?). YALNIZCA büyük şirketler için (Sağlık Hizmetleri, Finans) BİRÇOK inşa sunucusuyla çalışmış olsaydım, bunun aynı zamanda güvenlik ile ilgili olduğunu da eklemek isterim. Hiç Office Space filmini gördünüz mü? Hoşnutsuz bir geliştirici, yerel makinesinde bir bankacılık uygulaması oluşturursa ve kimse ona bakmaz veya onu test etmezse ... BOOM. Süpermen III.

Bu makineler, tümü üstün bir ürün sağlamanıza yardımcı olmak için çeşitli nedenlerle kullanılır.

Bir kullanım, tipik bir son kullanıcı yapılandırmasını simüle etmektir. Ürün, tüm geliştirme araçlarınız ve kitaplıklarınız kurulu olarak bilgisayarınızda çalışabilir, ancak son kullanıcı büyük olasılıkla sizinle aynı yapılandırmaya sahip olmayacaktır. Bu konuda, diğer geliştiriciler de sizinle aynı kuruluma sahip olmayacak. Kodunuzun herhangi bir yerinde sabit kodlanmış bir yolunuz varsa, muhtemelen makinenizde çalışacaktır, ancak Dev El O'per aynı kodu oluşturmaya çalıştığında işe yaramayacaktır.

Ayrıca ürünü kimin en son kırdığını, hangi güncellemeyle ve ürünün nerede gerilediğini izlemek için de kullanılabilirler. Her yeni kod kontrol edildiğinde, yapı sunucusu onu oluşturur ve başarısız olursa, bir şeylerin yanlış olduğu ve en son işlem yapan kullanıcının hatalı olduğu açıktır.

Tutarlı kalite için ve ortam hatalarını tespit etmek için 'makinenizden' derleme yapmak ve böylece kaynak kontrolüne eklemeyi unuttuğunuz dosyalar da derleme hataları olarak görünür.

Ayrıca, masaüstünde kod imzalama vb.İle yapmak çok zaman aldığından, yükleyiciler oluşturmak için de kullanıyorum.

Üretim / test kutularının, bu kitaplıkların yapı sunucusunda bulunanlarla aynı kitaplıklara ve sürümlere sahip olduğunu bilmemiz için bir tane kullanıyoruz.

Bizim için yönetim ve testle ilgili. Yapım sunucusu ile her zaman ana "ana" hattımızı sürüm kontrolünden oluşturabileceğimizi biliriz. Tek tıkla ana kurulum oluşturabilir ve web'de yayınlayabiliriz. Çalıştığından emin olmak için kod her kontrol edildiğinde tüm birim testlerimizi çalıştırabiliriz. Tüm bu görevleri tek bir makinede toplayarak, defalarca doğru şekilde yapmayı kolaylaştırır.

Geliştiricilerin kendi makinelerini inşa edebilecekleri konusunda haklısınız.

Ancak bunlar, derleme sunucumuzun bize satın aldığı şeylerden bazıları ve bizler pek de sofistike yapı oluşturucularız:

• Sürüm kontrol sorunları (bazıları önceki yanıtlarda belirtilmiştir)
• Verimlilik. Geliştiricilerin yerel olarak derleme yapmak için durması gerekmez. Sunucuda başlatabilir ve bir sonraki göreve geçebilirler. Yapılar büyükse, bu, geliştiricinin makinesinin meşgul olmadığı daha da fazla zaman demektir. Sürekli entegrasyon ve otomatik test yapanlar için daha da iyisi.
• Merkezileştirme. Derleme makinemiz, derlemeyi yapan, UAT ortamlarına ve hatta üretim aşamasına dağıtan komut dosyalarına sahiptir. Bunları tek bir yerde tutmak, senkronize tutma zahmetini azaltır.
• Güvenlik. Burada çok özel bir şey yapmıyoruz, ancak bir sistem yöneticisinin bunu, üretim taşıma araçlarına yalnızca belirli yetkili varlıklar tarafından bir derleme sunucusunda erişilebilecek şekilde yapabileceğinden eminim.

Belki de ben tekim ...

Sanırım herkes, birinin

• bir dosya deposu kullan
• depodan derlemeler yapın (ve temiz bir ortamda)
• "Düzeltmelerinizden" sonra herhangi bir sorun olup olmadığını görmek için sürekli bir test sunucusu (örneğin, hız sabitleyici) kullanın

Ancak otomatik olarak oluşturulan sürümler kimsenin umurunda değil. Otomatik yapıda bir şey kırıldığında, ancak artık olmadığı zaman - kimin umurunda? Devam eden bir çalışma. Biri onu düzeltti.

Bir yayın sürümü yapmak istediğinizde, depodan bir yapı çalıştırırsınız. Ve o anda depodaki sürümü etiketlemek istediğinizden oldukça eminim ve sunucu çalışırsa altı saatte bir değil.

Yani, belki bir "inşa sunucusu" sadece yanlış bir isimdir ve aslında "sürekli bir test sunucusu" dur. Aksi takdirde, kulağa oldukça faydasız geliyor.

Bir yapı sunucusu, kodunuz hakkında size bir tür ikinci fikir verir. Kontrol ettiğinizde kod kontrol edilir. Çalışırsa, kodun minimum kalitesi vardır.

Ek olarak, düşük seviyeli dillerin derlenmesinin yüksek seviyeli dillerden çok daha uzun sürdüğünü unutmayın. "Bakın, .Net projem birkaç saniye içinde derleniyor! Sorun nedir?" Diye düşünmek kolaydır. Bir süre önce bazı C kodlarıyla uğraşmak zorunda kaldım ve derlemenin ne kadar uzun sürdüğünü unutmuştum.

Bir derleme sunucusu, bazen birkaç saatten fazla sürebilen bir depoda bulunan genellikle büyük projelerin derleme görevlerini (örneğin, gecelik derlemeler) planlamak için kullanılır.

Bir yapı sunucusu ayrıca, başkalarının sahip olma haklarına sahip olabileceği durumlarda bir yapıyı yeniden oluşturmak için gerekli tüm parçaları yakalayabilmeniz için size emanet için bir temel sağlar.