Chcę być bardziej wydajny i chcę efektywnie korzystać z narzędzi operacyjnych.
Mając to na uwadze, chciałem dowiedzieć się więcej o ciągłej integracji, ale wydaje się, że jest wiele różnych rzeczy na ten temat.
Właściwie pracuję z kombinezonami Jetbrains w mojej pracy (IntelliJ, WebStorm ...), więc chciałem ich nadal używać i chciałem używać TeamCity, które wydawało się być doskonałym narzędziem z wieloma wtyczkami do ciągłej integracji.
Mój problem polega na tym, że nie wiem, jakie są różnice między:
automatyzacja budynku (TeamCity jest tego rodzaju oprogramowaniem): Wiem, że możemy zbudować naszą aplikację za pomocą zdalnego repozytorium VCS i jest świetna, ale jaki jest jej główny cel? Jakie informacje są przy tym ważne? W rzeczywistości już wiem, czy moje oprogramowanie buduje się lokalnie, czy też nie, a także moi koledzy z zespołu. Jaki jest więc cel korzystania z niego bez wdrażania automatyzacji?
wdrażanie automatyzacji (TeamCity nie robi tego łatwo)
- ciągła integracja (która wydaje się być połączeniem dwóch powyższych)
- ciągła dostawa (co to dokładnie? dlaczego różni się od ciągłej integracji?)
Czy możesz mi pomóc to trochę lepiej zrozumieć?
Odpowiedzi:
Wikipedia podaje całkiem dobre podsumowania większości tych terminów. Oto moje zdanie na ich temat:
Automatyzacja kompilacji to automatyzacja budowy oprogramowania zamiast ręcznego wywoływania kompilatora. Można to osiągnąć za pomocą narzędzi takich jak np. Make lub Ant .
Automatyzacja wdrażania polega na pobieraniu wbudowanego oprogramowania i wdrażaniu go lub instalowaniu w systemie testowym lub produkcyjnym.
Ciągła integracja środki mające zautomatyzowanym Build przetworzyć oprogramowania stale jako programiści sprawdzić w kodzie i uruchomić testy jednostkowe w celu zapewnienia kod nadal działa. Na przykład co 15 do 30 minut serwer może się budzić, skanować VCS w poszukiwaniu nowych meldowań, a następnie aktualizować i budować projekt, jeśli dokonano jakichkolwiek zmian. Oprócz wykonywania kroków kompilacji jest to także doskonała okazja do przeprowadzenia automatycznych testów jednostkowych i kontroli jakości kodu .
Ciągłe dostarczanie to połączenie wszystkich poprzednich koncepcji, w których kompilacje oprogramowania są również wdrażane w systemie testowym, opcjonalnie z przeprowadzonymi testami i generowanymi raportami.
Przynajmniej musisz mieć automatyzację kompilacji, tj. Pewnego rodzaju skrypt kompilacji. To pozwala kliknąć jeden przycisk lub wydać jedno polecenie, aby zbudować projekt. Zaletą tego jest zmniejszenie liczby błędów wynikających z ręcznego uruchamiania kroków. Złożone środowiska kompilacji mogą obejmować generowanie kodu (pomyśl DAO z konfiguracji, kod interfejsu, taki jak JAXB ), kompilowanie kodu, pakowanie go, dostosowywanie metadanych itp. Mając wiele rzeczy do zrobienia, potrzebujesz listy kontrolnej: dlaczego nie stworzyć listy kontrolnej? swój skrypt kompilacji i użyć narzędzia do jego uruchomienia? Redukuje błędy i zapewnia spójność.
Następny jest CI: to naprawdę dobrze mieć, ale nie jest to absolutnie wymagane. Pomaga wcześnie identyfikować problemy z kompilacją. Jeśli masz wielu programistów sprawdzających kod w ciągu dnia i być może nie synchronizujących stale własnych obszarów roboczych, istnieje ryzyko, że ich zmiany będą ze sobą kolidować. Mam na myśli w szczególności błędy kodu statycznego, a nie konflikty kontroli wersji. Serwer kompilacji CI zmniejszy to ryzyko.
Wreszcie mamy kroki wdrażania. Chodzi tu o oszczędność czasu i ograniczenie błędów związanych z ręcznym wdrażaniem oprogramowania. Podobnie jak w przypadku automatyzacji kompilacji, istnieje sto sposobów na zepsucie wdrożenia oprogramowania. Osobiście spóźniłem się w biurze, aby naprawić problemy z ręcznym wdrażaniem przy wielu okazjach, gdy potrzebujemy sprawnego systemu dla klientów, którzy jutro przyjdą na miejsce. Automatyzacja wielu systemów wiąże się z większym ryzykiem: zamiast jednego systemu, który może ulec awarii lub mieć dziwne błędy, mamy teraz wielesystemy, które mogą pójść nie tak. Ryzyko to jest jednak znacznie niższe niż w przypadku, gdy ktoś pominął krok na liście kontrolnej lub wydał niewłaściwe polecenie i zepsuł wdrożenie. Jeśli masz szczęście, możesz po prostu przywrócić kopię zapasową bazy danych i zacząć od nowa, jeśli masz pecha, błąd może spowodować nieprawidłowe działanie systemu. Czy to wada oprogramowania? Czy technik nie ustawił poprawnie konfiguracji? Zdiagnozowanie tego wymaga czasu, czasu, którego możesz nie mieć, i czasu, którego nie musisz poświęcać na automatyzację procesu.
źródło
Ciągła integracja to praktyka polegająca na łączeniu wszystkich zmian programistycznych we wspólną linię główną kilka razy dziennie. Ta praktyka jest obecnie tak wszechobecna, że może nie wydawać się tak znacząca, jednak tradycyjnie zespoły pracowałyby nad oprogramowaniem przez tygodnie, a nawet miesiące w izolacji. Rezultatem było „Piekło integracji”, kiedy oddzielne strumienie pracy zostały połączone. Ciągła integracja jest zwykle używana z automatycznymi kompilacjami wspólnej linii głównej, aby wcześnie znaleźć problemy, ale bardziej dotyczy częstych zatwierdzeń i przepływu pracy programistów niż DevOps.
Automatyczne kompilacje są cenne przy wykrywaniu problemów, które mogą powodować, że kompilacja przechodzi lokalnie, ale nie działa na serwerze kompilacji (np. Zapomniałeś sprawdzić plik, zależności na serwerze kompilacji nie pasują). Wykrycie przez serwer kompilacji tych problemów oznacza, że możesz je naprawić, zanim zrobią to Twoi koledzy z drużyny.
Ciągła dostawa obejmuje ciągłe wdrażanie, uruchamianie i testowanie oprogramowania. Chociaż automatyczne kompilacje zapewniają, że oprogramowanie faktycznie buduje się (a testy jednostkowe przebiegają pomyślnie), nie oznacza to, że skrypty wdrażania nadal działają lub że oprogramowanie faktycznie działa od końca do końca. Celem ciągłej dostawy jest przeprowadzenie szeregu kontroli, które zapewnią, że linia główna pozostanie w stanie odpowiednim do wdrożenia w produkcji.
Ciągłe wdrażanie jest kolejnym logicznym krokiem - automatyczne wdrażanie każdego zatwierdzenia, które pomyślnie przejdzie przez potok ciągłego dostarczania. Jest kilka korzyści z tej praktyki, ale dla mnie główna idea jest taka, że małe, częste zmiany są mniej ryzykowne.
Polecam przeczytanie tej książki, aby uzyskać więcej informacji:
źródło
Teamcity, podobnie jak wiele narzędzi do kompilacji, to tylko centralna aplikacja, która pozwala na uruchamianie wielu różnych zadań. Obejmuje to wykonywanie kompilacji takich jak kompilacje CI, kompilacje z pełną wersją i pozwala na wdrażanie. Jeśli używasz teamcity do wywołania ant lub nant w celu uruchomienia msbuild na pliku rozwiązania, możesz także wywołać skrypty nant, które wykonają wdrożenia. Może wymagać trochę skryptów, ale nie jest to trudne.
Używamy teamcity i bambusa do tworzenia pełnych CI, baz danych CI i wdrożeń w środowisku integracyjnym. Następnie używamy teamcity do kompilacji pełnej wersji i automatycznego tworzenia skryptów migracji db. Są one sprawdzane w SVN za pośrednictwem zadań teamcity wywołujących skrypty nant. W przypadku wdrożeń, zgadłeś, używamy teamcity, aby wezwać nanta do wykonania zadań wdrożeniowych. Działa to dobrze, ponieważ agent teamcity rozmawia z serwerem teamcity, a agent może istnieć na jednym z serwerów w lokalizacji DMZ, co pomaga w przenoszeniu kodu poza zapory ogniowe itp. Więc teamcity lub bambus to wszystko, czego potrzebujesz, aby obsłużyć cały scenariusz .
źródło