W latach programowania Java, a ostatnio Scali, nigdy nie używałem Anta, Mavena, Gradle'a ani żadnego z tych narzędzi do budowania Javy. Wszędzie, gdzie pracowałem, był menedżer kompilacji, który zadbał o to wszystko - skompilowałem lokalnie z IDE do programowania i testów jednostkowych, następnie sprawdziłem kod źródłowy i powiadomiłem menedżera kompilacji, który zrobił to, co było konieczne, aby skompiluj pliki wszystkich dla wspólnego środowiska.

Teraz, gdy jestem między umowami, pracuję nad własnym, samofinansującym się projektem i dochodzę do punktu, w którym może być wystarczająco dobry, aby zarabiać pieniądze. Mam nawet potencjalnego inwestora w kolejce i planuję pokazać mu wersję beta w ciągu najbliższych kilku tygodni.

Ale przez cały czas po prostu klikam przycisk kompilacji w IDE, a on tworzy plik Jar i działa dobrze. Oczywiście, konwencjonalna mądrość sugeruje, że „powinienem” pisać własne skrypty Ant / Maven / Gradle i używać ich zamiast IDE, ale jakie są konkretne zalety tego w mojej sytuacji (praca w pojedynkę)?

Przeczytałem trochę o tym, jak korzystać z tych narzędzi do budowania i wygląda na to, że napisałbym setki wierszy XML (lub Groovy lub cokolwiek innego), aby zrobić to, co robi IDE jednym kliknięciem (wygenerowane przez IDE Ant XML dla projektu to ponad 700 linii). Po prostu wygląda na podatną na błędy, czasochłonną i niepotrzebną w mojej sytuacji. Nie wspominając już o krzywej uczenia się, która zabrałaby czas na całą resztę pracy, którą wykonuję, aby przygotować produkt do pokazywania ludziom.

Sugerowałbym, aby rozważyć użycie Maven w przeciwieństwie do Anta. Jeśli Twoje IDE może zbudować projekt za pomocą jednego kliknięcia, prawdopodobnie Maven może również zbudować projekt praktycznie bez konfiguracji niestandardowej.

Aby odpowiedzieć na pytanie, uproszczenie procesu wdrażania jest jednym konkretnym przykładem. Jeśli budujesz dystrybucję lokalnie, oznacza to, że musisz ręcznie wdrożyć tę dystrybucję w systemie produkcyjnym, i oznacza to, że prawdopodobnie musiałeś wykonać sporo ręcznej konfiguracji w systemie produkcyjnym, aby przygotować ją do wdrożenia (instalacja Tomcat , być może lub kopiowanie zależności i zasobów wymaganych przez aplikację). Może to być czasochłonne i może spowodować, że wdrażanie aktualizacji stanie się żmudnym, ręcznym procesem. Pozwala również na potencjalne niewielkie różnice w konfiguracji między platformą produkcyjną a środowiskiem programistycznym, powodując niejasne i trudne do wyśledzenia błędy.

Tak czy inaczej, aby pozbyć się tej ręcznej znęcania się, konfiguruję mój projekt do budowania za pomocą Maven i konfiguruję mój pom.xmlplik ze wszystkimi informacjami wymaganymi (w przypadku aplikacji internetowej Java) do znalezienia i pobrania poprawną wersję Tomcat, zainstaluj ją lokalnie, skonfiguruj prawidłowe pliki konfiguracyjne Tomcat, wdróż wszelkie zależności projektu i sam plik WAR projektu, a następnie uruchom Tomcat. Następnie tworzę prosty skrypt powłoki (a także .batwersję dla systemu Windows), która używa Maven do zbudowania i uruchomienia serwera:

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

Zamiast pakować oprogramowanie do wdrożenia w moim środowisku programistycznym, a następnie ręcznie wypychać je do środowiska produkcyjnego, wystarczy zsynchronizować system kontroli wersji z serwerem produkcyjnym, a następnie sam system produkcyjny kompiluje się, instaluje i uruchamia do wdrożenia (i robi to w sposób identyczny jak w każdym systemie programistycznym, minimalizując możliwość wystąpienia błędów lub błędnych konfiguracji specyficznych dla platformy). Niezależnie od tego, czy w środowisku programistycznym, czy produkcyjnym, wszystko, co robię, aby zbudować i uruchomić serwer, to:

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

Aby wdrożyć aktualizację w środowisku produkcyjnym, proces jest po prostu:

1. Zatrzymaj działającą instancję serwera, jeśli istnieje.
2. Uruchom svn update -r<target_release_revision>.
3. Uruchom ./startServer.sh.

Jest to proste, łatwe do zapamiętania i wcale nie jest możliwe, gdybym polegał na użyciu mojego IDE do zbudowania dla mnie narzędzia do wdrożenia. Powoduje również, że powrót do ostatniego znanego dobrego wdrożenia jest bardzo prosty, jeśli cofnięcie kiedykolwiek będzie konieczne.

Nie mogę nawet policzyć czasu, jaki to podejście zaoszczędziło mi na próbie ręcznego zarządzania procesem wdrażania i konfiguracji.

I oczywiście inną odpowiedzią na twoje pytanie jest automatyczne zarządzanie zależnościami, ale uważam, że zostały już uwzględnione w innych odpowiedziach.

Tak długo, jak twój kod jest pod kontrolą źródła, używanie IDE do tworzenia dystrybucji jest w porządku.

Czy jako sklep jednoosobowy lepiej poświęcić czas na dodawanie nowych funkcji do produktu lub pisanie skryptów kompilacji? Coś mi mówi, że nie pisze skryptów kompilacji.

Jasne, trudniej dostrzec korzyści, gdy pracujesz sam. Osobiście pracowałem nad wieloma solowymi projektami i nie tylko napisałem skrypt kompilacji, ale i tak mam problem z konfiguracją serwera CI (takiego jak Jenkins).

Oczywiście jest narzut, dlaczego warto?

• Odtwarzalna kompilacja niepowiązana z IDE (lub maszyną, jeśli uruchamiasz ją zewnętrznie). Jeśli serwer kompilacji go uruchamia, inne komputery mogą go uruchomić.
• Zabawa zaczyna się po testach budynku i testów jednostkowych (przy okazji: czy na pewno testujesz przed każdym zatwierdzeniem? Czasami zapominam). Generuj dokumentację, twórz instalatory, uruchamiaj ulubione narzędzia do analizy kodu.
• Twój ulubiony serwer CI umożliwia wyświetlanie wykresów pokrycia kodu, błędów testów jednostkowych itp. W czasie. Czy twoje IDE to robi?

W moim bieżącym projekcie skrypt buduje, uruchamia narzędzia analizy statycznej, kompresuje plik js / css, testy jednostkowe i pakiety do archiwum internetowego. Jenkins uruchamia go po każdym zatwierdzeniu i wdraża projekt na serwerze testowym.

Poświęciłem czas, aby to skonfigurować (przy okazji, skrypt kompilacji może mieć 300 linii, nie dotykałem go od miesięcy) i mogę powiedzieć, że warto, nawet dla jednej osoby. Dla więcej niż jednej osoby jest to konieczne. Moje zaangażowanie w proces kompilacji / wdrażania składa się z poleceń „hg commit” i „hg push”.

Korzyści z narzędzi do budowania

To krótkie podsumowanie pokazujące wierzchołek góry lodowej i niekoniecznie zwrócisz uwagę na to wszystko, chyba że będziesz musiał zrobić to z wieloma projektami, dużymi projektami i średnim i dużym zespołem. Ale jeśli masz wiarę i spróbujesz, będziesz czerpać korzyści .

Ułatwiają cykl rozwoju oprogramowania i umożliwiają:

• zorganizować i uporządkować swoje projekty konsekwentnie i bez wysiłku
• ponownie wykorzystuj dobre praktyki w różnych projektach i łatwo i szybko je uruchom ,
• zintegrować wiele projektów w jednym kompilacji,
• zautomatyzować swoją ciągłej integracji procesu
• udostępnij swój projekt innym osobom
  • bez zmuszania ich do używania określonego zestawu narzędzi lub IDE (oprócz systemu kompilacji),
  • i nie dziwi ich, ponieważ będą oczekiwać standardowej wersji
• zautomatyzowanie i ułatwienie do utrzymania swojego produktu
• zautomatyzuj proces wydawania produktu

Jeśli zastosujemy to do Maven ...

Dla tych z was, którzy żyją w Javie i którzy korzystają z Maven , czytając to naturalnie kojarzysz każdy punkt z:

• Zorganizowana konwencja projektu Mavena
• Archetypy Maven
• Materializacja projektu z SCM i kompilacji reaktorów
• Wsparcie Jenkins / Hudson / Bamboo / other + wsparcie Maven dla praktyk testowania integracji
• Obsługa m2eclipse, natywna obsługa IntelliJ lub NetBeans - lub mvnsh dla wiersza poleceń
• wersje-maven-plugin
• maven-release-plugin, buildnumber-maven-plugin plugin i wersje-maven-plugin

I oczywiście Maven (ale także inne narzędzia) zapewnia zarządzanie zależnościami , a to ogromna oszczędność czasu i miejsca dla ciebie (biorąc pod uwagę liczbę osób w zespole) i twojego SCM.

Wszystko jest względne:

Korzystam z Maven jako przykładu, ponieważ uważam, że jest to najbardziej wszechstronny i oparty na bateriach system kompilacji, ale to nie znaczy, że niekoniecznie jest on „najlepszy”. Pasuje jednak do wszystkich wymienionych powyżej pól wyboru, a gdy szukam dobrego systemu kompilacji, porównuję go do tej listy i Maven. Jednak Maven nie zawsze jest bardzo elastyczny - jest jednak bardzo rozszerzalny - jeśli odejdziesz od standardowego procesu. Zwiększa to produktywność w ogólnym przypadku (raz przed krzywą uczenia się), nie jeśli się z nią walczy.

Oto moje 4 główne powody, dla których warto korzystać z narzędzi do budowania:

• obsługa zależności (unikaj błędów)
• testowanie (twoja zmiana nie zepsuła innych modułów - znacznie łatwiej przetestować)
• bezpieczne zobowiązania
• łatwiejsze do wdrożenia lokalnego dystrybuowalnego (nikt nie ma czasu w QV env, aby poczekać, aż konstruktor zbuduje projekt i jego zależności)

W książce Pragmatic Programmer Andrew Hunt i David Thomas mówią, że „kasa-budowanie-testowanie-wdrażanie” powinno być pojedynczym poleceniem (rozdział: Projekty pragmatyczne). Napisałeś..

Mam nawet potencjalnego inwestora w kolejce i planuję pokazać mu wersję beta w ciągu najbliższych kilku tygodni

W takim razie jestem pewien, że Twój zespół będzie się powiększał. Jeszcze ważniejsze jest wykonanie automatycznych umiejętności testowania.

Duży plik XML (skrypt), który widziałeś, jest zwykle jednorazowy. Przez większość czasu te same skrypty mogą być używane w wielu projektach.

Nie jest jasne, jak duży jest ten projekt. Jeśli zintegrowane testy / testy akceptacyjne zajmują duży procesor / pamięć, możesz rozważyć użycie innej maszyny jako serwera testowego. Możesz także wdrożyć wiele narzędzi do analizy kodu źródłowego / kodu bajtowego .

Argumentowałbym, że dla samotnego programisty dobry proces i struktura, takie jak kompilacje skryptowe, są znacznie ważniejsze niż w zespole. Powodem jest to, że nie masz kolegów z drużyny, którzy mogliby cię zawołać, gdy skręcisz na zakręcie. Serwer CI z uruchomionym skryptem kompilacji to świetny bezkompromisowy członek zespołu, który zapewnia uczciwość.

W miarę wzrostu bazy kodu będziesz chciał dodać pakiet testowy. Z mojego doświadczenia wynika, że ​​należy to zrobić wcześniej niż później i że twoja nocna (lub cokolwiek) kompilacja powinna uruchamiać wszystkie testy za każdym razem. Zacznij od małego, automatycznie wygenerowany XML jest prawdopodobnie w porządku. Jeśli boisz się coś zmienić, aby nie złamać czegoś innego, to dobra zachęta do napisania kilku przypadków testowych.

Kompilacja inna niż IDE ułatwia odbudowę starych wersji bez obawy o zmianę konfiguracji IDE w takim stanie, w jakim była w tym czasie, pozwala na wykonanie kompilacji w sposób nieinteraktywny, dzięki czemu można zachować kompilację nocną dla osób testujących lub szybko się dowiedzieć jeśli przeszedłeś testy bez konieczności pamiętania o ich uruchomieniu i czekaniu na ich zakończenie.

Pozwala także na wykonywanie kompilacji w środowiskach innych niż GUI, np. Ssh'ing na serwer, i pozwala na przełączanie IDE bez obawy o utratę możliwości tworzenia oprogramowania.

Niektóre narzędzia do budowania pomagają zautomatyzować oznaczanie i wdrażanie wydań, mają przyzwoite wartości domyślne do generowania raportów pokrycia kodu itp.

Gdy dodasz więcej osób, narzędzie kompilacji zapewni, że nie będziesz narażony na słabą konfigurację IDE innej osoby. Regularnie robię zrzuty ekranu, aby naprawić instalacje Eclipse kolegów, ponieważ nie używają narzędzi do budowania (pracują nad tym).

Ostatecznym powodem jest jednak to, że nie trzeba tego robić ręcznie, więc nie rób tego ręcznie. Wszystko inne wypada z tego.