rozumiem ale nie taniej i łatwiej byłoby po prostu odpalić w konsoli np ( w przypadku asp.net : dotnet test) i sprawdzić czy działa? przeciez to tez jedno kliknięcie
Jak masz CI/CD to wypychając zmiany za pomocą git push, takie rzeczy dzieją się automatycznie gdzieś na serwerze. Definiujesz sobie jakiegoś hooka na Jenkinsie powiązanego z repozytorium gita i ten od razu się odpala, gdy zobaczy nowego commita. DevOps to jest w ogólności podejście/sposób do developingu i deploymentu. Główną ideą jest jak najszybsze reagowanie na niepożądane zmiany w produkcie końcowym i jednoczesne niezwłoczne przygotowanie produktu, co w konsekwencji ogranicza straty finansowe firmy.
A teraz przykład jak to wygląda w praktyce, mając podpięte CI/CD do projektu. Tworzycie kod w 10 osób, kod ma być napisany jak najlepiej, nie żadne spaghetti. Z tego powodu żaden z Was nie może bezpośrednio wypchnąć zmian na gałąź master/main. Każda zmiana musi przejść proces jakości, aby dołączyć do gałęzi głównej, a więc w konsekwencji trafić do projektu.
Piszecie kod + testy. Na każdą funkcjonalność tworzycie nową gałąź od mastera. Wypychacie zmiany na tę gałąź, a kiedy uznacie, że funkcjonalność jest gotowa, to otwieracie merge/pull requesta. Już przed otwarciem merge requesta każdy wypchnięty commit powiadamia Jenkinsa, który może zrobić takie rzeczy jak:
- odpalić unit testy i sprawdzić, czy wszystkie przechodzą
- odpalić testy integracyjne, które np. mogą wymagać sprzętu, którego deweloper nie posiada
- zrobić automatyczne kod review, np. za pomocą SonarQube
- sprawdzić pokrycie kodu testami
- sprawdzić złożoność obliczeniową
Z każdego takiego narzędzia deweloper, który rozwija funkcjonalność, może otrzymać maila z raportem z tych narzędzi. W ten sposób od razu wie, czy wszystko gra, czy coś należy poprawić.
W przypadku, gdy wszystko będzie w porządku i skończył on funkcjonalność, to otwiera merge requesta. W takim przypadku te raporty z ostatniego commita dostają wszyscy deweloperzy, którzy będą brali udział w review kodu + Jenkins w tle łączy tego merge requesta z najnowszym masterem buduje aplikacje (np. poprzez skomplikowanie kodu). Powiadomienie o zbudowanej aplikacji wysyłane jest do testerów.
W ten sposób wszyscy zainteresowani otrzymują odpowiednie powiadomienia. Jak np. kod jest zepsuty na merge requeście to nie ma sensu go reviewować, ani testować zbudowanej aplikacji. Dopiero po otrzymaniu wymaganych akceptacji przez zespół deweloperów i testerów jest w ogóle możliwość zmergowania kodu do mastera.
Ten proces może wyglądać jak overkill, ale spróbuj sobie wyobrazić sytuację, w której Facebook czy Youtube publikuje nową odsłonę swoich serwisów, do których nie można się zalogować, jeśli w loginie użytkownika jest kropka. Delikatnie mówiąc, jest to pożar :)
