Czy skrypt wdrażania powinien być artefaktem kompilacji?


13

To jest projekt internetowy napisany w Javie.

Piszę więc skrypty kompilacji i wdrażania. Do stworzenia kompilacji użyłem mrówki. Ciągłe budowanie odbywa się za pomocą Jenkinsa.

Kompilacja generuje 3 różne artefakty:

  1. Plik wojenny
  2. Zamek błyskawiczny z układami
  3. Zamek z obrazami

Jak dotąd tak dobrze, ale teraz muszę napisać skrypt wdrażania, który powinien:

  • Przeprowadź wojnę (artefakt 1) do kocura działającego na serwerze 1
  • Umieść artefakt 2 na serwerze 1 w określonym katalogu
  • Umieść artefakt 3 na serwerze 2 w określonym katalogu

Rozmawiałem więc z moim kolegą i powiedział, że powinniśmy również wygenerować artefakt (być może deploy.xml ), który rozmieszcza te artefakty, gdy zostaną umieszczone na właściwym serwerze.

Byłby więc inny skrypt, który:

  • Pobierz artefakty Jenkins
  • scp na każdy serwer i umieść tam plik deploy.xml
  • zdalnie wywołać plik deploy.xml

To, co sprawia, że ​​czuję się trochę nieswojo, to fakt posiadania pliku deploy.xml jako artefaktu kompilacji. Motywacją do tego byłaby możliwość wdrożenia bez konieczności posiadania dostępu do repozytoriów VCS, więc kompilacja byłaby samodzielna, tj. Każda kompilacja mogłaby wejść do produkcji tylko z tym, co wygenerowała Jenkins.

Gdzie należy umieścić skrypty wdrażania? Czy powinni być tylko w VCS, czy też powinni też budować artefakty?


to pytanie jest dobre / sprawia, że ​​chcemy mieć plus-jeden / chciałbym odpowiedzieć
amara

Odpowiedzi:


6

Z mojego doświadczenia wynika, że powinno być wszystko, co można zautomatyzować. Jeśli możesz opisać to jako krok 1, krok 2, .... to powinien to być skrypt. Jeśli skrypt można wygenerować automatycznie, aby zawierał informacje o kompilacji (np. Tag rewizji), to powinieneś to zrobić. Nie chodzi o to, by być leniwym, ale o to, aby być przewidywalnym i powtarzalnym .

Uwaga bene: powinieneś mieć również automatycznie generowany skrypt przywracania, z którego może korzystać każdy w zespole, na wypadek, gdyby automatycznie wygenerowany skrypt wdrażania nie zwariował i nie doprowadził do awarii serwera produkcyjnego.


3

Wszystko, co napisał Peter Rowell, jest poprawne, a ponadto:

Dla pliku skryptu wdrażania

  • jeśli został napisany przez kogoś, musi mieć kontrolę wersji.
  • jeśli został wygenerowany i może zostać wygenerowany ponownie, zwykle nie przechodzi do kontroli wersji.

W przypadku procesu wdrażania:

  • Jeśli podoba Ci się, że twoje artefakty są samodzielne i jeśli można to łatwo zrobić, plik może być artefaktem kompilacji, co oznacza, że ​​jest spakowany z wynikiem kompilacji w taki sposób, że można go użyć do wdrożenia.
  • Z drugiej strony, wdrożenia stają się coraz bardziej złożone, więc prędzej czy później będziesz potrzebować dedykowanego programu (przeczytaj kod), który wykonuje wdrożenie, a artefakt kompilacji Jenkinsa nie jest już samodzielny.

Zależy to raczej od twojego procesu i tego, jak lubisz obsługiwać wdrożenia.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.