A jednak nie odpowiedzia\u0142e\u015b na pytanie: \u201eCzy Jenkins jest potrzebny, czy nie?\u201d<\/em><\/p>\n<\/p>\n
Jenkins w rzeczywisto\u015bci nie jest potrzebny w \u017cadnym przypadku. Je\u015bli m\u00f3wimy powa\u017cnie, narz\u0119dzia: Jenkins, Gitlab przynie\u015b\u0107 wygod\u0119. Zobaczysz, czy kompilacja si\u0119 uda\u0142a, czy nie. Mog\u0105 ci pom\u00f3c, ale nie zapewni\u0105 ci praktyki. Mog\u0105 tylko da\u0107 znacznik \u2013 Ok, nie Ok. I to, je\u015bli piszesz jeszcze testy, bo je\u015bli nie masz test\u00f3w, to to jest prawie bezsensowne. Dlatego jest potrzebny, poniewa\u017c \u2013 to bardziej wygodne, ale w og\u00f3le mo\u017cna bez niego \u017cy\u0107, nie stracisz zbyt wiele. <\/p>\n
<\/p>\n
T. j. je\u015bli masz praktyki, to znaczy, \u017ce nie jest ci potrzebny?<\/em><\/p>\n<\/p>\n
Zgadza si\u0119. Polecam test Jez Humbles. Mam mieszane uczucia co do ostatniego punktu. Ale og\u00f3lnie, je\u015bli masz trzy rzeczy, ci\u0105gle si\u0119 \u0142\u0105czysz, uruchamiasz testy na commitach w masterze, szybko naprawiasz build w masterze, to by\u0107 mo\u017ce, \u017ce nie potrzebujesz nic wi\u0119cej. <\/p>\n
<\/p>\n
Jak czekamy na pytania od uczestnik\u00f3w, mam pytanie. M\u00f3wili\u015bmy teraz o kodzie produktowym. A czy u\u017cywa\u0142e\u015b tego do kodu infrastrukturalnego? To taki sam kod, ma te same zasady i ten sam cykl \u017cycia, czy s\u0105 tam inne cykle \u017cycia i zasady? Zwykle, gdy wszyscy m\u00f3wi\u0105 o Integracji i Rozwoju Ci\u0105g\u0142ym, zapominaj\u0105, \u017ce jest jeszcze kod infrastrukturalny. I ostatnio jest go coraz wi\u0119cej. Czy nale\u017cy tam wprowadza\u0107 wszystkie te zasady?<\/em><\/p>\n<\/p>\n
Nawet nie to, czy nale\u017cy, to b\u0119dzie \u015bwietne, poniewa\u017c na pewno upro\u015bci to \u017cycie. Gdy tylko pracujemy z kodem, nie ze skryptami na bash, a mamy normalny kod.<\/p>\n
<\/p>\n
Stop, stop, skrypt na bash \u2013 to te\u017c jest kod. Nie dotykaj mojej starej mi\u0142o\u015bci.<\/em> <\/p>\n<\/p>\n
Dobrze, nie b\u0119d\u0119 st\u0105pa\u0107 po twoich wspomnieniach. Mam osobist\u0105 niech\u0119\u0107 do basha. Psuje si\u0119 brzydko i strasznie ca\u0142y czas. I psuje si\u0119 cz\u0119sto w spos\u00f3b nieprzewidywalny, wi\u0119c go nie lubi\u0119. Ale dobrze, za\u0142\u00f3\u017cmy, \u017ce masz kod w bashu. Mo\u017ce rzeczywi\u015bcie si\u0119 nie znam i s\u0105 tam normalne frameworki do testowania. Po prostu nie jestem w temacie. I w takim razie mamy te same zalety.<\/p>\n
<\/p>\n
Kiedy pracujemy z infrastruktur\u0105 jak z kodem, mamy te same problemy co programi\u015bci. Kilka miesi\u0119cy temu natkn\u0105\u0142em si\u0119 na sytuacj\u0119, w kt\u00f3rej kolega przes\u0142a\u0142 mi pull request na 1000 linii basha. I utkn\u0105\u0142e\u015b na recenzji przez 4 godziny. Problemy s\u0105 te same. To nadal kod. I nadal wsp\u00f3\u0142praca. Utkn\u0119li\u015bmy z pull request i utkn\u0119li\u015bmy z tym, \u017ce musimy rozwi\u0105zywa\u0107 te same konflikty merge w tym samym bashu, na przyk\u0142ad. <\/p>\n
<\/p>\n
Obecnie bardzo aktywnie przygl\u0105dam si\u0119 ca\u0142emu temu procesowi maksymalnie pi\u0119knym programowaniem infrastruktury. Wprowadzi\u0142em do infrastruktury Pulumi. To czystsze programowanie. Tam jest to jeszcze bardziej atrakcyjne, poniewa\u017c mam wszystkie mo\u017cliwo\u015bci j\u0119zyka programowania, wi\u0119c z tymi samymi ifami zrobi\u0142em eleganckie prze\u0142\u0105czniki w powietrzu i wszystko dzia\u0142a dobrze. To znaczy, moja zmiana znajduje si\u0119 ju\u017c w ga\u0142\u0119zi master. Ju\u017c wszyscy to widz\u0105. Inni in\u017cynierowie s\u0105 tego \u015bwiadomi. Ju\u017c mia\u0142o to na co\u015b wp\u0142yw. Ale w tym czasie w\u0142\u0105czy\u0142o si\u0119 to nie dla ca\u0142ej infrastruktury. W\u0142\u0105czy\u0142o si\u0119 to na przyk\u0142ad dla moich testowych \u015brodowisk. Dlatego odpowiadaj\u0105c na twoje pytanie jeszcze raz, jest to potrzebne. Nam, jako in\u017cynierom pracuj\u0105cym z kodem, znacznie u\u0142atwia \u017cycie. <\/p>\n
<\/p>\n
Czy s\u0105 jeszcze jakie\u015b pytania?<\/em> <\/p>\n<\/p>\n
Mam pytanie. Chc\u0119 kontynuowa\u0107 dyskusj\u0119 z Olegiem. Og\u00f3lnie my\u015bl\u0119, \u017ce masz racj\u0119, \u017ce je\u015bli zadanie zajmuje ci miesi\u0105c, to masz problem z architektur\u0105, masz problem z analiz\u0105, dekompozycj\u0105, planowaniem itd. Ale mam takie wra\u017cenie, \u017ce je\u015bli zaczniesz pr\u00f3bowa\u0107 \u017cy\u0107 wed\u0142ug continuous integration, to zaczniesz rozwi\u0105zywa\u0107 b\u00f3le zwi\u0105zane z planowaniem, poniewa\u017c nie uciekniesz od tego. <\/p>\n
<\/p>\n
(Oleg) Tak, to prawda. W zakresie nak\u0142ad\u00f3w praca ta jest por\u00f3wnywalna z ka\u017cd\u0105 inn\u0105 powa\u017cn\u0105 praktyk\u0105 zmieniaj\u0105c\u0105 kultur\u0119. Najtrudniejsze w przezwyci\u0119\u017caniu s\u0105 przyzwyczajenia, zw\u0142aszcza te z\u0142e. A je\u015bli aby wdro\u017cy\u0107 t\u0119 praktyk\u0119 wymagana jest znacz\u0105ca zmiana nawyk\u00f3w otoczenia: deweloper\u00f3w, zarz\u0105du, mened\u017cera produkcji, czekaj\u0105 na was niespodzianki.<\/em> <\/p>\n<\/p>\n
Jakie mog\u0105 by\u0107 niespodzianki? Przypu\u015b\u0107my, \u017ce postanowili\u015bcie cz\u0119\u015bciej przeprowadza\u0107 integracje. I w przypadku integracji zale\u017c\u0105 od siebie r\u00f3\u017cne rzeczy, na przyk\u0142ad artefakty. A w waszej firmie mo\u017ce istnie\u0107 polityka, \u017ce ka\u017cdy artefakt musi by\u0107 w jaki\u015b spos\u00f3b uwzgl\u0119dniony w systemie archiwizacji artefakt\u00f3w. I to zajmuje pewn\u0105 ilo\u015b\u0107 czasu. Osoba musi zaznaczy\u0107, \u017ce jako mened\u017cer wydania zatwierdzi\u0142a ten artefakt do produkcji. Je\u015bli to zajmuje 5-10-15 minut, ale przeprowadzacie wydanie raz w tygodniu, to wydanie raz w tygodniu zajmowa\u0142oby p\u00f3\u0142 godziny \u2013 to niewielki podatek.<\/em> <\/p>\n<\/p>\n
Je\u015bli robisz Continuous Integration 10 razy dziennie, to 10 razy trzeba pomno\u017cy\u0107 przez 30 minut. I to przekracza ilo\u015b\u0107 czasu pracy tego mened\u017cera wydania. Po prostu si\u0119 m\u0119czy to robi\u0107. Istniej\u0105 sta\u0142e koszty dla r\u00f3\u017cnych praktyk. I to wszystko.<\/em> <\/p>\n<\/p>\n
I musisz albo anulowa\u0107 t\u0119 zasad\u0119, aby nie zajmowa\u0107 si\u0119 takimi sprawami, tzn. nie przypisujesz r\u0119cznie poziomu zgodno\u015bci czego\u015b z czym\u015b. Ca\u0142kowicie polegasz na jakim\u015b zautomatyzowanym zestawie test\u00f3w gotowo\u015bci.<\/em> <\/p>\n<\/p>\n
A je\u015bli musisz uzyska\u0107 od kogo\u015b potwierdzenie, aby szef podpisa\u0142, i nie wchodzisz do produkcji bez tego, \u017ce Wania powiedzia\u0142, \u017ce to dozwolone itd. \u2013 wszystkie te bzdury stan\u0105 na drodze praktykom. Poniewa\u017c je\u015bli s\u0105 jakie\u015b zwi\u0105zane dzia\u0142ania w postaci podatku, wszystko 100 razy si\u0119 zwi\u0119ksza. Dlatego zmiana nie zawsze jest przyjmowana z entuzjazmem. Poniewa\u017c trudno jest zmienia\u0107 nawyki ludzi.<\/em> <\/p>\n<\/p>\n
Kiedy cz\u0142owiek wykonuje znan\u0105 prac\u0119, robi to praktycznie bez zastanowienia. Obci\u0105\u017cenie poznawcze jest r\u00f3wne zeru. Po prostu dzia\u0142a wed\u0142ug ustalonych procedur, ma w g\u0142owie list\u0119 kontroln\u0105, robi\u0142 to tysi\u0105ce razy. I gdy tylko przychodzisz i m\u00f3wisz mu: \u201eZrezygnujmy z tej praktyki i od poniedzia\u0142ku wdro\u017cymy now\u0105\u201d, dla niego staje si\u0119 to powa\u017cnym obci\u0105\u017ceniem poznawczym. A jednak obci\u0105\u017ca to wszystkich jednocze\u015bnie.<\/em> <\/p>\n<\/p>\n
Dlatego najpro\u015bciej, chocia\u017c w rzeczywisto\u015bci nie wszyscy mog\u0105 sobie na to pozwoli\u0107, ja zawsze post\u0119puj\u0119 dok\u0142adnie w ten spos\u00f3b, to jest nast\u0119puj\u0105ce. Kiedy rozpoczyna si\u0119 nowy projekt, zwykle od razu wpychane s\u0105 do niego wszystkie nieprzetestowane praktyki. Dop\u00f3ki projekt jest m\u0142ody, w\u0142a\u015bciwie nie ryzykujemy. Produkcja jeszcze nie istnieje, nie ma czego rozwali\u0107. Dlatego mo\u017cna to wykorzysta\u0107 jako trening. Takie podej\u015bcie dzia\u0142a. Ale nie wszystkie firmy maj\u0105 mo\u017cliwo\u015b\u0107 cz\u0119sto rozpoczyna\u0107 takie projekty. Chocia\u017c to te\u017c jest troch\u0119 dziwne, bo teraz trwa pe\u0142na transformacja cyfrowa, wszyscy powinni uruchamia\u0107 eksperymenty, aby dogoni\u0107 konkurencj\u0119.<\/em> <\/p>\n<\/p>\n
Tutaj natrafiasz na to, \u017ce najpierw musisz zrozumie\u0107, co musisz zrobi\u0107. \u015awiat nie jest idealny, produkcja te\u017c nie jest idealna. <\/p>\n
<\/p>\n
Tak, te rzeczy s\u0105 ze sob\u0105 powi\u0105zane.<\/em><\/p>\n<\/p>\n
Biznes te\u017c nie zawsze ma zrozumienie, \u017ce powinien i\u015b\u0107 dok\u0142adnie w tym kierunku. <\/p>\n
<\/p>\n
S\u0105 sytuacje, w kt\u00f3rych jakiekolwiek zmiany s\u0105 ca\u0142kowicie niemo\u017cliwe. To sytuacja, gdy na zesp\u00f3\u0142 wywierane jest wi\u0119ksze ci\u015bnienie. Zesp\u00f3\u0142 jest ju\u017c ca\u0142kiem wypalony. Nie ma \u017cadnego zapasu czasu na eksperymenty. Od rana do wieczora pracuj\u0105 nad funkcjami. A kierownictwu ci\u0105gle ma\u0142o i ma\u0142o tych funkcji. Wymagana jest coraz wi\u0119ksza liczba. W takiej sytuacji jakiekolwiek zmiany s\u0105 ca\u0142kowicie niemo\u017cliwe. Zespo\u0142owi mo\u017cna tylko powiedzie\u0107, \u017ce jutro zrobimy tak samo jak wczoraj, po prostu musimy zrobi\u0107 troch\u0119 wi\u0119cej funkcji. \u017badne przej\u015bcia do jakichkolwiek praktyk w tym sensie nie s\u0105 mo\u017cliwe. To klasyczna sytuacja, w kt\u00f3rej nie ma czasu na ostrzenie topora, trzeba r\u0105ba\u0107 drzewa, wi\u0119c r\u0105bi\u0105 t\u0119py toporem. Tutaj nie ma prostych rad.<\/em> <\/p>\n<\/p>\n
(Dmitrij) Przeczytam doprecyzowanie z czatu: \"Ale potrzebne jest du\u017ce pokrycie testami na r\u00f3\u017cnych poziomach. Ile czasu po\u015bwi\u0119ca si\u0119 na testy? To jako\u015b drogo, zajmuje du\u017co czasu.\"<\/em><\/p>\n<\/p>\n
(Oleg) To jest klasyczne nieporozumienie. Test\u00f3w powinno by\u0107 wystarczaj\u0105co du\u017co, aby\u015bcie sami mieli pewno\u015b\u0107. Continuous Integration to nie jest taka rzecz, gdzie najpierw przeprowadza si\u0119 100% test\u00f3w, a dopiero potem zaczyna si\u0119 wdra\u017ca\u0107 t\u0119 praktyk\u0119. Continuous Integration zmniejsza obci\u0105\u017cenie poznawcze, poniewa\u017c ka\u017cda z widocznych zmian jest na tyle oczywista, \u017ce rozumiecie, czy co\u015b si\u0119 zepsuje, nawet bez test\u00f3w. Mo\u017cecie to szybko przetestowa\u0107 w my\u015blach, poniewa\u017c zmiany s\u0105 ma\u0142e. Nawet je\u015bli macie tylko tester\u00f3w manualnych, im te\u017c jest \u0142atwiej. Wypu\u015bcili\u015bcie now\u0105 wersj\u0119 i powiedzieli\u015bcie: \u201eSp\u00f3jrz, nic si\u0119 nie zepsu\u0142o?\u201d. Oni sprawdzili i powiedzieli: \u201eNie, nic si\u0119 nie zepsu\u0142o\u201d. Poniewa\u017c tester wie, na co zwr\u00f3ci\u0107 uwag\u0119. Mo\u017cecie mie\u0107 jeden commit zwi\u0105zany z jednym fragmentem kodu. I to eksploduje w konkretne zachowanie.<\/em><\/p>\n<\/p>\n
Tutaj oczywi\u015bcie lekko przesadzi\u0142e\u015b. <\/p>\n
<\/p>\n
(Dmitriy) Z tym si\u0119 nie zgodz\u0119. Istnieje praktyka \u2013 rozw\u00f3j przez testowanie, kt\u00f3ra w\u0142a\u015bnie ratuje przed tym.<\/em> <\/p>\n<\/p>\n
(Oleg) Jeszcze do tego nie doszed\u0142em. Pierwsz\u0105 iluzj\u0105 jest to, \u017ce trzeba pisa\u0107 dok\u0142adnie 100% test\u00f3w lub w og\u00f3le nie zajmowa\u0107 si\u0119 Continuous Integration. To nieprawda. To s\u0105 dwie r\u00f3wnoleg\u0142e praktyki. I one nie s\u0105 od siebie bezpo\u015brednio zale\u017cne. Wasze pokrycie testami powinno by\u0107 optymalne. Optymalne oznacza, \u017ce sami jeste\u015bcie pewni, \u017ce jako\u015b\u0107 mastera, w kt\u00f3rej pozostanie po commicie wasz master, pozwala wam z pewno\u015bci\u0105 nacisn\u0105\u0107 przycisk \u201eDeploy\u201d w pi\u0105tek wieczorem, b\u0119d\u0105c pod wp\u0142ywem alkoholu. Jak to osi\u0105gniecie? Dzi\u0119ki przegl\u0105dowi, dzi\u0119ki pokryciu, dzi\u0119ki dobremu monitoringowi.<\/em> <\/p>\n<\/p>\n
Dobry monitoring jest nierozr\u00f3\u017cnialny od test\u00f3w. Je\u015bli uruchamiacie testy raz na pre-prod, to sprawdzaj\u0105 one wszystkie wasze scenariusze u\u017cytkownika tylko raz. A je\u015bli uruchamiacie je w niesko\u0144czonej p\u0119tli, to jest wasz rozbudowany system monitorowania, kt\u00f3ry testuje wszystko w niesko\u0144czono\u015b\u0107 \u2013 czy system pad\u0142, czy nie. W tym przypadku r\u00f3\u017cnica polega tylko na jednorazowo\u015bci lub wielokrotno\u015bci. Bardzo dobry zestaw test\u00f3w, kt\u00f3ry \u2026 jest uruchamiany bez ko\u0144ca, to monitorowanie. I prawid\u0142owy monitoring powinien by\u0107 taki.<\/em> <\/p>\n<\/p>\n
I dlatego jak dok\u0142adnie osi\u0105gniecie ten stan, kiedy w pi\u0105tek wieczorem wdro\u017cycie now\u0105 wersj\u0119 i wr\u00f3cicie do domu, to ju\u017c inna kwestia. Mo\u017ce po prostu jeste\u015bcie odwa\u017cnym szale\u0144cem.<\/em> <\/p>\n<\/p>\n
Cofnijmy si\u0119 nieco do Continuous Integration. Troch\u0119 odbiegli\u015bmy w stron\u0119 innej skomplikowanej praktyki. <\/p>\n
<\/p>\n
Druga iluzja to przekonanie, \u017ce MVP nale\u017cy szybko wytwarza\u0107, wi\u0119c testy w og\u00f3le nie s\u0105 potrzebne. To nie do ko\u0144ca prawda. Gdy piszesz user story w MVP, mo\u017cesz j\u0105 rozwija\u0107 albo na spontanicznie, tzn. us\u0142ysza\u0142e\u015b, \u017ce istnieje jaka\u015b user story i od razu przyst\u0119pujesz do kodowania, albo pracuj\u0105c wg TDD. Z praktyki wynika, \u017ce w przypadku TDD nie trwa to d\u0142u\u017cej, tzn. testy to efekt uboczny. Praktyka TDD nie polega na testowaniu. Mimo \u017ce nazywa si\u0119 to Test Driven Development, to w rzeczywisto\u015bci chodzi bardziej o podej\u015bcie architektoniczne. To metoda, jak pisa\u0107 dok\u0142adnie to, co jest potrzebne, a nie pisa\u0107 rzeczy niepotrzebne. Ta praktyka koncentruje si\u0119 na nast\u0119pnej iteracji twojego rozwoju my\u015bli w zakresie tworzenia architektury aplikacji.<\/em> <\/p>\n<\/p>\n
Dlatego tak trudno pozby\u0107 si\u0119 tych iluzji. MVP i testy nie wykluczaj\u0105 si\u0119 nawzajem. Wr\u0119cz przeciwnie, je\u015bli tworzysz MVP w praktyce TDD, zrobisz to lepiej i szybciej ni\u017c bez tej praktyki, na \u015blepo.<\/em><\/p>\n<\/p>\n
To bardzo nieoczywista i skomplikowana my\u015bl. Kiedy s\u0142yszysz, \u017ce teraz b\u0119d\u0119 pisa\u0142 jeszcze testy i przy tym co\u015b zrobi\u0119 szybciej, brzmi to absolutnie absurdalnie. <\/p>\n
<\/p>\n
(Dmitrij) Tutaj wielu, kiedy m\u00f3wi o MVP, po prostu nie chce im si\u0119 napisa\u0107 czegokolwiek sensownego. To dwie r\u00f3\u017cne rzeczy. Nie nale\u017cy przekszta\u0142ca\u0107 MVP w co\u015b z\u0142ego, co nie dzia\u0142a.<\/em> <\/p>\n<\/p>\n
Tak, masz racj\u0119.<\/p>\n
<\/p>\n
A potem nagle MVP w prod.<\/em><\/p>\n<\/p>\n
Na zawsze. <\/p>\n
<\/p>\n
A TDD brzmi bardzo dziwnie, gdy s\u0142yszysz, \u017ce piszesz testy i wydaje si\u0119, \u017ce wykonujesz wi\u0119cej pracy. To brzmi do\u015b\u0107 dziwnie, ale w rzeczywisto\u015bci sprawia, \u017ce idzie to szybciej i przyjemniej. Gdy piszesz test, ju\u017c w g\u0142owie my\u015blisz o tym, jaki kod i jak b\u0119dzie wywo\u0142ywany, a tak\u017ce jakie zachowanie od niego oczekujemy. Nie po prostu m\u00f3wisz, \u017ce napisa\u0142e\u015b jak\u0105\u015b funkcj\u0119, kt\u00f3ra co\u015b robi. Najpierw my\u015blisz, \u017ce ma takie i takie warunki, tak b\u0119dzie wywo\u0142ywana. Pokrywasz to testami i z tego rozumiesz, jak b\u0119d\u0105 wygl\u0105da\u0142y interfejsy wewn\u0105trz twojego kodu. To ma ogromny wp\u0142yw na architektur\u0119. Tw\u00f3j kod automatycznie staje si\u0119 bardziej modularny, poniewa\u017c najpierw pr\u00f3bujesz zrozumie\u0107, jak b\u0119dziesz go testowa\u0107, a dopiero potem go piszesz. <\/p>\n
<\/p>\n
W moim przypadku z TDD by\u0142o tak, \u017ce w pewnym momencie zatrudni\u0142em mentora do Ruby, kiedy jeszcze by\u0142em programist\u0105 Ruby. I on m\u00f3wi: 'Zr\u00f3bmy to w TDD'. Pomy\u015bla\u0142em: 'O nie, teraz musz\u0119 pisa\u0107 co\u015b dodatkowo'. Uzgodnili\u015bmy, \u017ce przez dwa tygodnie b\u0119d\u0119 pisa\u0107 ca\u0142y dzia\u0142aj\u0105cy kod w Pythonie w TDD. Po dw\u00f3ch tygodniach zrozumia\u0142em, \u017ce ju\u017c nie chc\u0119 wraca\u0107. Pr\u00f3buj\u0105c to wdra\u017ca\u0107 przez dwa tygodnie, zrozumia\u0142em, jak bardzo u\u0142atwi\u0142o mi to my\u015blenie. Ale to nie jest oczywiste, dlatego wszystkim polecam, \u017ce je\u015bli macie wra\u017cenie, \u017ce TDD to skomplikowane, d\u0142ugie i niepotrzebne, spr\u00f3bujcie stosowa\u0107 to przez dwa tygodnie. Dwa by\u0142y wystarczaj\u0105ce dla mnie.<\/p>\n
<\/p>\n
(Dmitrij) Mo\u017cemy rozwin\u0105\u0107 t\u0119 my\u015bl z perspektywy eksploatacji infrastruktury. Zanim uruchomimy co\u015b nowego, robimy monitorowanie, a potem uruchamiamy. W takim przypadku nasze monitorowanie staje si\u0119 normalnym testowaniem. I jest rozw\u00f3j poprzez monitorowanie. Ale prawie wszyscy m\u00f3wi\u0105, \u017ce to trwa d\u0142ugo, nie chce mi si\u0119, zrobi\u0142em tymczasowy szkic. Je\u015bli zrobili\u015bmy monitorowanie we w\u0142a\u015bciwy spos\u00f3b, rozumiemy stan systemu CI. A w systemie CI jest du\u017co monitorowania. Rozumiemy stan systemu, wiemy, co si\u0119 w nim dzieje. I podczas rozwoju robimy system, aby osi\u0105gn\u0105\u0107 po\u017c\u0105dany stan.<\/em> <\/p>\n<\/p>\n
Te praktyki s\u0105 znane od dawna. Rozmawiali\u015bmy o tym jakie\u015b 4 lata temu. Ale przez 4 lata praktycznie nic si\u0119 nie zmieni\u0142o.<\/em> <\/p>\n<\/p>\n
Na tej nucie proponuj\u0119 zako\u0144czy\u0107 oficjaln\u0105 dyskusj\u0119.<\/em><\/p>\n<\/p>\n
Wideo (wstawione jako element multimedialny, ale z jakiego\u015b powodu nie dzia\u0142a):<\/p>\n
\nhttps:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex> habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u0431\u0441\u0443\u0434\u0438\u043c \u043f\u043e\u0447\u0435\u043c\u0443 CI-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 CI \u2013 \u044d\u0442\u043e \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u0440\u043e \u0440\u0430\u0437\u043d\u043e\u0435. \u041a\u0430\u043a\u0443\u044e \u0431\u043e\u043b\u044c CI \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c, \u043e\u0442\u043a\u0443\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u043b\u0430 \u0438\u0434\u0435\u044f, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0447\u0442\u043e \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0435\u0441\u0442\u044c \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044b\u0439 Jenkins. \u041c\u044b\u0441\u043b\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0434\u043e\u043a\u043b\u0430\u0434 \u043f\u0440\u043e Continuous Integration \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0435\u0449\u0435 \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434, \u043a\u043e\u0433\u0434\u0430 \u044f \u0445\u043e\u0434\u0438\u043b \u043f\u043e \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u0438\u0441\u043a\u0430\u043b \u0440\u0430\u0431\u043e\u0442\u0443. \u041f\u043e\u043e\u0431\u0449\u0430\u043b\u0441\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93885","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Continuous](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n