Java programlamam ve yıllar süren Scala programlarında, Ant, Maven, Gradle veya Java için oluşturulmuş araçlardan hiç kullanmadım. Çalıştığım her yerde, bununla ilgilenen bir yapı yöneticisi vardı - yerel olarak geliştirme ve birim testi için IDE ile derlerdim, sonra kaynak kodunu kontrol eder ve gerekli olanı yapan yapı yöneticisine bildirirdim. paylaşılan ortam için herkesin dosyalarını derleyin.

Şimdi kendi kendime finanse edilen projem üzerinde çalıştığım sözleşmeler arasındayım ve aslında para kazanmanın yeterince iyi olabileceği bir noktaya geliyorum. Hatta potansiyel bir yatırımcının sıraya girmesini ve önümüzdeki birkaç hafta içinde onlara beta versiyonunu göstermeyi planlıyorum.

Ama baştan beri IDE'deki derleme düğmesine basıyorum ve Jar dosyasını yaratıyor ve gayet iyi çalışıyor. Elbette, geleneksel bilgelik, kendi Ant / Maven / Gradle senaryolarımı "yazmam" gerektiğini ve IDE yerine bunu kullanmamı önerir, fakat benim durumumda bunun somut avantajları nelerdir?

Bu oluşturma araçlarının nasıl kullanılacağı hakkında bazı okumalar yaptım ve görünüşe göre yüzlerce satır XML (veya Groovy veya ne olursa olsun) yazıyordum, IDE'nin tek bir tıklamayla ne yaptığını yapmak için (IDE tarafından üretilen) Proje için karınca XML 700 satırdan fazladır). Sadece durumum için hataya eğilimli ve zaman alıcı ve gereksiz görünüyor. Ürünü insanlara göstermeye hazır hale getirmek için yaptığım tüm diğer çalışmalardan zaman alacak olan öğrenme eğrisinden bahsetmiyorum bile.

Maven’i Ant’a karşı kullanmanı öneririm. IDE'niz projenizi tek bir tıklamayla oluşturabilirse, Maven projenizi neredeyse hiç özel bir yapılandırma olmadan da oluşturabilir.

Ve soruyu cevaplamak için, dağıtım sürecini basitleştirmek somut bir örnektir. Yerel olarak dağıtılabilir bir yapı inşa ediyorsanız, bu, üretim sisteminize dağıtılabilir olanı manuel olarak dağıtmanız gerektiği anlamına gelir ve üretim sistemine dağıtmak için hazır olması için büyük olasılıkla üretim sisteminde el ile biraz elle yapılandırma yapmanız gerektiği anlamına gelir (Tomcat'ı yükleme , belki de, ya da başvurunuzun gerektirdiği bağımlılıklar ve kaynaklar üzerine kopyalama yapılması). Bu zaman alabilir ve güncellemeleri dağıtmanın sıkıcı ve manuel bir işlem haline gelmesine neden olabilir. Ayrıca, üretim platformunuz ile geliştirme ortamınız arasındaki ufak konfigürasyon farklılıklarının, hataların izlenmesinin zor ve belirsiz olmasına neden olma olasılığını da sağlar.

Her neyse, bu manüel zorbalığın kurtulmak için yaptığım şey, projemi Maven ile inşa etmek üzere yapılandırmam ve dosyamı pom.xmlgereken bilgileri (Java web uygulaması söz konusu olduğunda) bulmak ve indirmek için yapılandırmam . Tomcat sürümünü düzeltin, yerel olarak kurun, doğru Tomcat yapılandırma dosyalarını kurun, proje bağımlılıklarını ve proje WAR dosyasının kendisini dağıtın ve Tomcat'i başlatın. Daha sonra .bat, sunucuyu oluşturmak ve başlatmak için Maven'i kullanan basit bir kabuk betiği (ve ayrıca Windows için bir sürüm) oluşturuyorum:

mvn clean install cargo:start -Dcargo.maven.wait=true

Bu yüzden, dev ortamımda konuşlandırılabilir bir paketleme yapmak ve daha sonra manuel olarak üretime zorlamak yerine tek yapmam gereken, sürüm kontrol sisteminden üretim sunucusuna eşitleme yapmak ve ardından üretim sisteminin kendisi oluşturuyor, kuruyor ve çalışıyor konuşlandırılabilir (ve herhangi bir geliştirme sisteminde nasıl yapıldığına özdeş bir şekilde yapar , platforma özgü hata veya yanlış yapılandırma olasılığını en aza indirir). Geliştirme veya üretim ortamında, sunucuyu oluşturmak ve başlatmak için tek yaptığım şey:

./startServer.sh #or startServer.bat for Windows

Ve üretim ortamına bir güncelleme dağıtmak için süreç tam da şudur:

1. Varsa, çalışan sunucu örneğini durdurun.
2. Run svn update -r<target_release_revision>.
3. Run ./startServer.sh.

Basit, hatırlaması kolay ve benim için konuşlandırılabilir bir yapı oluşturmak için IDE'mi kullanmaya güveniyorsam bunu yapmak mümkün değil. Ayrıca, en son bilinen iyi konuşlandırmaya geri dönülmesini bir geri çekilme gerekliyse, bir çırpıda yapar.

Dağıtım ve yapılandırma işlemini el ile yönetmeye çalışırken bu yaklaşımın bana kazandırdığı süreyi bile sayamıyorum.

Ve elbette, sorunuza bir başka cevap otomatik bağımlılık yönetimidir, ancak bunun zaten başka cevaplar tarafından ele alındığına inanıyorum.

Kodunuz kaynak kontrolü altında olduğu sürece, dağıtımlarınızı yapmak için IDE'yi kullanmak iyidir.

Tek kişilik bir dükkan olarak, ürününüze yeni özellikler ekleyerek veya derleme komut dosyaları yazarak zaman geçirmeniz daha mı iyi? Bir şey bana onun derleme senaryoları yazmadığını söylüyor.

Tabii, yalnız çalışırken yararları görmek zor. Şahsen, birçok solo projede çalıştım ve sadece bir senaryo yazmam değil, bir CI Sunucusu (Jenkins gibi) kurma zorluğundan da geçeceğim.

Elbette ek yükü var, neden buna değer?

• IDE'ye (ya da harici olarak çalıştırıyorsanız makinenize) bağlı olmayan tekrarlanabilir bir yapı. Bir derleme sunucusu çalışıyorsa, diğer makineler de çalıştırabilir.
• Eğlence, bina ve birim testinden sonra başlar (bu arada: Her işlemden önce test ettiğinizden emin misiniz? Bazen unuturum). Dokümantasyon oluşturun, yükleyiciler oluşturun, en sevdiğiniz kod analiz araçlarını çalıştırın.
• Favori CI sunucunuz zamanla kod kapsamı grafiklerini, birim test hatalarını vb. Görmenizi sağlar. IDE'niz bunu yapıyor mu?

Mevcut projem için, komut dosyası oluşturur, statik analiz araçları çalıştırır, js / css, birim testleri ve paketleri web arşivi halinde sıkıştırır. Jenkins her taahhütten sonra çalıştırır ve projeyi bir test sunucusuna dağıtır.

Bunu ayarlamak için zaman ayırdım (derleme betiği belki 300 satırdır, aylardır dokunmamış) ve bir kişi için bile buna değer diyebilirim. Birden fazla kişi için bu gereklidir. Yapım / konuşlandırma sürecine katılmam, "hg commit" ve "hg push" komutlarından oluşur.

Yapı Araçlarının Yararları

Bu sadece buzdağının tepesini gösteren kısa bir özettir ve birçok projenin, büyük projelerin ve orta ila büyük ekibin bir kombinasyonu ile yapmanız gerekmediği sürece bunların önemini fark etmeyeceksiniz. Fakat inancınız ve denemeniz durumunda, avantajlardan yararlanacaksınız .

Gelişim ömrünüzü kolaylaştırır ve size izin verdiği gibi:

• projelerinizi tutarlı ve zahmetsizce düzenleyin ve yapılandırın
• Projeler arasında iyi uygulamaları yeniden kullanmak ve bunları kolay ve hızlı bir şekilde başlatmak ,
• Birden fazla projeyi tek bir yapıya entegre etmek,
• otomatikleştirmek için sürekli entegrasyon süreci
• Projenizi başkalarıyla paylaşın
  • Belirli bir araç seti veya IDE kullanmaya zorlamadan (yapım sisteminden ayrı olarak),
  • ve standart bir yapı bekledikleri için onları şaşırtmadan
• otomatikleştirmek ve kolaylaştırmak bakım ürününüzün
• ürününüzün sürüm sürecini otomatikleştirin

Bunu Maven'e uygularsak ...

Java dünyasındakiler ve Maven'i kullananlar için , bunu okuyarak her bir noktayı doğal olarak ilişkilendirdin:

• Maven'in yapılandırılmış proje toplantısı
• Maven Arketipler
• SCM'den bir projenin hayata geçirilmesi ve reaktör inşa edildi
• Jenkins / Hudson / Bamboo / diğer destek + Maven'in entegrasyon testi uygulamaları için desteği
• m2eclipse, native IntelliJ veya NetBeans desteği - veya komut satırı için mvnsh
• versiyonları-maven-plugin
• maven-release-eklentisi, buildnumber-maven-eklentisi eklentisi ve sürümleri-maven-eklentisi

Ve elbette, Maven (fakat diğer araçlar da) size bağımlılık yönetimi verir ve bu sizin (ekibinizdeki insan sayısına göre) ve SCM'niz için çok büyük bir zaman ve alan tasarrufu sağlar.

Herşey Göreceli:

Maven'i örnek olarak kullanıyorum, çünkü bunun en kapsamlı ve "piller dahil" yapı sistemi olduğunu düşünüyorum, ancak bunun mutlaka "en iyi" olduğu anlamına gelmiyor. Yukarıda listelenen tüm onay kutularına uyuyor ve iyi bir yapı sistemi ararken, bu liste ve Maven ile karşılaştırıyorum. Bununla birlikte, Maven her zaman çok esnek değildir - ancak çok genişletilebilirdir - eğer standart işleminizden saparsanız. Genel durumdaki (öğrenme eğrisinin önünde bir kez) veriminizi artırır, savaşmazsanız.

İşte derleme araçlarını kullanmak için en iyi 4 nedenim:

• bağımlılık yönetimi (hataları önlemek)
• test (değişikliğiniz diğer modülleri bozmadı - test etmesi çok daha kolay)
• güvenli taahhütler
• Yerel dağıtılabilir dağıtım yapmak daha kolay (hiç kimsenin projenizi ve bağımlılıklarını inşa etmesini beklemek için KG env'de vakti yok)

Pragmatic Programmer adlı kitabında Andrew Hunt ve David Thomas, “check-build-test-test-konuşlandırmanın” tek bir komut olması gerektiğini söylüyorlar (Bölüm: Pragmatic Projects). Sen yazdın..

Hatta potansiyel bir yatırımcının sıraya girmesini ve önümüzdeki birkaç hafta içinde onlara beta versiyonunu göstermeyi planlıyorum.

O zaman, ekibinizin büyüyeceğinden eminim .. Otomatik test dağıtma yeteneklerinin yapılması daha da önemlidir.

Gördüğünüz büyük XML (script) tipik olarak bir kerelik bir iştir. Çoğu zaman, aynı komut dosyaları birçok projede kullanılabilir.

Projenin ne kadar büyük olduğu belli değil. Entegre testleriniz / kabul testleriniz büyük CPU / bellek alıyorsa, test sunucunuz olarak başka bir makine kullanmayı düşünebilirsiniz. Ayrıca kaynak kodunu / bayt kodunu analiz etmek için bir dizi araç dağıtabilirsiniz .

Yalnız bir geliştirici için, komut dosyası oluşturulmuş yapılar gibi iyi bir sürece ve yapıya sahip olmanın, bir takımda olduğunuzdan çok daha önemli olduğunu savunuyorum. Sebep, köşeleri kestiğinde seni arayacak takım arkadaşların olmaması. Derleme betiğinizi çalıştıran bir CI sunucusu sizi dürüst tutmak için ödünsüz bir takım arkadaşı sunar.

Kod tabanınız büyüdükçe bir test paketi eklemek isteyeceksiniz. Benim deneyimim, bunun bir an önce değil de yapılması gerektiği ve sizin gece (veya ne olursa olsun) yapınızın her seferinde tüm testleri yapması gerektiğidir. Küçük başlayın, otomatik olarak oluşturulan XML büyük olasılıkla iyidir. Başka bir şeyi kırma korkusuyla bir şeyleri değiştirmekten korktuğunuzda, birkaç test vakası yazmak için iyi bir teşviktir.

IDE olmayan bir yapı, eski sürümleri, IDE'nizi o zamanki gibi yeniden yapılandırma endişesi olmadan yeniden oluşturmayı kolaylaştırır, yapıyı etkileşimli olmayan bir şekilde gerçekleştirmenize izin verir; eğer testleri çalıştırmayı hatırlamak zorunda kalmadan testleri kırdıysanız ve tamamlanmasını bekleyin.

Ayrıca, GUI olmayan ortamlarda, örneğin bir sunucuya ssh'ing oluşturmalar gerçekleştirmenize izin verir ve IDE'leri yazılımınızı oluşturma yeteneğini kaybetme konusunda endişelenmeden değiştirmenize olanak tanır.

Bazı oluşturma araçları, sürümleri etiketleme ve dağıtma işlemlerini otomatikleştirmenize, kod kapsamı raporları oluşturmak için iyi varsayılan ayarlara sahip olmanıza yardımcı olur.

Daha fazla kişi eklediğinizde, bir oluşturma aracı başkasının zayıf IDE yapılandırmasına karşı korunmasız olduğunuzdan emin olmanızı sağlar. Meslektaşlarımın Eclipse kurulumlarını düzeltmek için düzenli olarak ekran paylaşımları yapıyorum çünkü derleme araçları kullanmıyorlar (üzerinde çalışıyorlar).

Nihai sebep, bunun elle yapılması gerekmeyen bir şey olmasıdır, bu yüzden el ile yapmayın. Her şey ondan düşer.