Przekonaj samotnego programistę, aby używał osobnego narzędzia do budowania zamiast kompilacji IDE jednym kliknięciem

22

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.

Gigatron
źródło
3
Chociaż na pewno powinieneś pomyśleć o możliwości użycia skryptów Ant / Maven / Gradle do obsługi procesu kompilacji. Z pewnością może poczekać do późniejszej fazy cyklu rozwoju. Nie komplikuj spraw. Kiedy jesteś na dobrej drodze, aby wydać coś, co można sprzedać i mieć inwestora, a kiedy wykracza poza to, rozważ to. Ponieważ na pewno NIE BĘDZIE to zadanie „zrób to raz i zapomnij”. Będziesz musiał aktualizować skrypt, aby pasował do twoich procedur kompilacji. Martw się o skrypty, gdy masz pomoc.
Ramhound
5
Narzędzia do budowania stają się przydatne, gdy masz do czynienia z czymś więcej niż „najnowszą wersją zawierającą cały najnowszy kod”. Jeszcze cię tam nie ma - w tej chwili oswajaj swoją kompilację.
8
Jeśli to, co robisz, teraz działa i nie powoduje żadnych problemów - po prostu kontynuuj. „Przedwczesne naprawianie” prawdopodobnie powoduje więcej problemów niż „przedwczesna optymalizacja”. Poza tym twoje IDE prawdopodobnie używa Anta pod przykryciem.
James Anderson
1
Bardzo ważne pytanie
Madhur Ahuja,

Odpowiedzi:

11

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.

aroth
źródło
1
Będę kontynuował kompilację IDE jednym kliknięciem, dopóki nie wyłoni się pierwsza wersja beta. Więc planuję użyć Maven. Wydaje się, że Mrówka tworzy więcej pracy, niż zaoszczędziłaby na moją sytuację, ale Maven wydaje się być na tyle prosty i silny, że warto. Dla mnie nie chodzi tylko o to, czy narzędzie do budowania ma jakąś korzyść; Ważę także koszty jego nauki, konfiguracji i utrzymania.
Gigatron
7

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.

Nate
źródło
7
Nie zgadzam się 1000 razy. Jeśli poprawnie skonstruujesz skrypty kompilacji, naprawdę będziesz musiał zapłacić tylko za ich napisanie, a następnie będziesz mógł ich ponownie używać niemal dosłownie w dowolnej liczbie projektów. Jest wiele do powiedzenia na temat posiadania jednowierszowego polecenia kompilacji, które buduje, konfiguruje, wdraża i uruchamia system automatycznie. Gdy to zrobisz, pozwoli to zaoszczędzić mnóstwo czasu w porównaniu z ręcznym wdrażaniem / zarządzaniem konfiguracją, które można następnie wydać na wspomniane nowe funkcje.
aroth
Zgadzam się, że sklep jednoosobowy musi się koncentrować. Nie zgadzam się z twoim założeniem, ponieważ narzędzia do budowania pozwoliłyby zaoszczędzić czas w dłuższej perspektywie, zarówno w celu przygotowania nowych projektów i utrzymania istniejących, a nawet w celu dostarczenia klientom produktów na żądanie.
haylem
Subtelną zaletą Maven jest to, że działa najlepiej ze standardowym układem plików, w przeciwieństwie do ad-hoc często obserwowanego w projektach Ant. Kiedy ludzie widzą zalety korzystania z domyślnych ustawień Maven, używają ich, a ich projekty są łatwiejsze do zrozumienia dla przyszłych opiekunów.
1
@aroth Ale OP wcale nie spędza czasu na „ręcznym wdrażaniu / zarządzaniu konfiguracją”, po prostu naciska przycisk w swoim IDE. Więc nie zaoszczędziłoby to wcale czasu.
Atsby
1
IDE to system kompilacji. W przeciwnym razie nie używałbym tego.
Arne Evertsson,
5

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”.

Kryptic
źródło
W rzeczy samej. Rzeczywistą rzeczą, którą programista powinien wziąć pod uwagę, jest dobre rozwiązanie CI, a skrypt kompilacji może pomóc w ich uzyskaniu.
Bill Michell
4

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.

Haylem
źródło
3

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)

źródło
1
Szczególnie obsługa zależności. Jestem zbyt leniwy, aby pobierać i dodawać biblioteki zewnętrzne. Znacznie prostsze jest dodanie ich jako zależności. „Zła wersja? Zmień wersję w config i przebuduj!”
Tak, ale obsługa zależności nie jest tak naprawdę warunkiem wstępnym wszystkich narzędzi do budowania. Obsługują go Maven, Gradle, Ivy. Mrówka, marka itp. Nie.
haylem
2

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 .

Jayan
źródło
1

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ść.

Wyatt Barnett
źródło
dokładnie to, o czym myślałem! Obecnie pracuję w miejscu, w którym każdy programista pracuje sam nad swoim projektem. Nie byłem jeszcze w stanie sprzedać im idei systemu kompilacji, ale sam go używam, ponieważ myślę, że to naprawdę pomaga.
elias
0

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.

potrójny
źródło
1
Przeprowadzam już testy jednostkowe bez potrzeby stosowania osobnego narzędzia do budowania. IDE może uruchomić testy lub mogę je uruchomić z wiersza poleceń.
0

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.

Ricky Clarkson
źródło