Cześć @piotr-galas, interesujący i wyczerpujący komentarz :) Dzięki!
Muszę się zgodzić w 100% w kwestii instalacji i konfiguracji Jenkins'a, może to być mozolny proces. Zaczynając z Jenkinsem niejednokrotnie potrzebowałem pomocy administratora, mnóstwo czasu poświęciłem na poszukiwania, instalację i konfigurację wtyczek, a i tak koniec końców pojawiały się problemy. Raz zdarzyło się nawet, że ktoś dostał się do naszego serwera produkcyjnego właśnie poprzez Jenkins'a (build'y były deploy'owane przez SSH-plugin, a Jenkins dostępny z zewnątrz) i odpalił tam sobie algorytm do kopania krytowalut :)
Wydaje mi się, że w dzisiejszych czasach lepiej jest zapłacić za CI i nie poświęcać czasu na konfigurowanie go.
Zgadzam się, natomiast dodałbym od siebie, że niekoniecznie musi to być najlepsza decyzja, gdy potrzebujemy rozwiązania 'szytego na miarę', choćby ze względu na niezliczoną ilość wtyczek do Jenkins, o których wspomniałeś. W przypadku małego zespołu, trafiłeś w sedno.
Powiem szczerze, że po przeczytaniu Twojego komentarza, zaczynam się poważnie zastanawiać nad przetestowaniem Pipelines. Chodziło mi to po głowie od jakiegoś czasu, choćby ze względu na to, że w zespole korzystamy z BitBucket'a - brakowało mi jednak wystarczającego bodźca :)
P.S.: Skoro jesteśmy już przy temacie CI, to czy może ktoś słyszał/korzystał z TeamCity (od JetBrains)?
Korzystałem z TeamCity, na jednym projekcie, ale byłem juniorem i nie zastanawiałem się nad koniguracją. Projekt bazował na testach integrayjnych które trwały straszną ilość czasu. Nie pamiętam dokładnie ile, ale na pewno ponad 1h. TeamCity jakoś sobie z tym radziło. Było kilka równoległych workerów( chyba 4).
Kiedy odchodziłem z projektu, były pomysły aby zmienć TeamCity, bo koszty były zbyt wysokie.
Odnośnie CI i wyboru najodpowiedniejszego polecam fajny artykuł
https://codete.com/blog/make-apps-not-infrastructure/
Z TeamCity co prawda nie korzystałem, ale używam Bamboo i jestem bardzo zadowolony (z bitbucketem)