dddddddd
dddddddd
  • 0
@szpongiel @LiczbaPi To nie jest moje podejście, tzn nie jestem jego autorem ( ͡° ͜ʖ ͡°) Jeżeli potrzebujecie większego autorytetu, to objerzyjcie tego devtalka http://devstyle.pl/2016/12/05/devtalk45-o-continuous-delivery-z-lukaszem-szydlo/ albo tego juga https://www.youtube.com/watch?v=kTX45JGCRYU nie powiem wam więcej na ten temat, zresztą bez sensu jest powtarzanie tego. A poza tym nie chce mi się przerzucać przez parę dni na cytaty. No i jak jeden drugiemu będzie udowadniał, że jest mądrzejszy.
U nas się
  • Odpowiedz
dddddddd
dddddddd
  • 0
@szpongiel: kurde

obniżenia jakości i spójności kodu (brak reviews)


mamy

obniżenia jakości samej aplikacji (brak CI i QA przed wejściem do mastera)


ciągła integracja na środowisku oraz od razu z pracą innych, a nie po mergu

rozwalania pracy innym deweloperom (brak CI przed wejściem do mastera)


szybki feedback, że coś nam się nie zgrywa, nie dopiero po mergu

bałagan w historii comitów


rzecz dyskusyjna

Wcale nie twierdzę, żę cd to tylko
  • Odpowiedz
dddddddd
dddddddd
  • 0
@LiczbaPi:

zwłaszcza, że nie raz na etapie testów znajdowałem naprawdę poważne błędy które prześlizgnęły się przez unit testy


no i nic dziwnego, jeżeli były tylko unit testy

dodatkowo w takim commicie trzebaby naraz wrzucać kod i testy modułowe, integracyjne


tdd, a integracja pomiędzy serwisami nie odbywa się codebasie aplikacji

No i w zasadzie co w przypadku gdy CI znajdzie bład?


Najczęściej (niezależnie od podejścia) takie rzeczy sie fixuje (⌐ ͡
  • Odpowiedz
dddddddd
dddddddd
  • 0
@LiczbaPi: jeżeli sądzisz, że w twojej architekturze takie podejście się nie aplikuje, to najwidoczniej tak jest i na pewno nie będę Cię przekonywał, że jest inaczej. Zauważ, że można i gdzie indziej robi się inaczej. Zachęcam jeszcze raz to obejrzenia jednego z dwóch linków powyżej, tak dla poszerzenia horyzontów
  • Odpowiedz
  • Hej dddddddd, może napiszesz coś o sobie i uzupełnisz dane w profilu?

Osiągnięcia