Поглед към разликите, които вие и вашият екип ще искате да знаете
Обзалагам се, че всеки разработчик на софтуер знае какво е Jenkins или поне е чувал за него. Това е инструмент с отворен код, написан главно на Java и само преди няколко години беше най-популярният инструмент за CI/CD.
От друга страна, CircleCI е сравнително нов инструмент SaaS, който започна да набира популярност през 2017 г. През 2022 г. все повече и повече разработчици, които познавам, преминават към CircleCI и аз бях един от тях, въпреки че не беше само мой избор.
CircleCI е в тежка разработка
Когато започнах да използвам CircleCI, нямаше възможност да стартирам Pipeline от потребителския интерфейс и го намерих за голям минус в сравнение с Jenkins, но след няколко месеца видях, че са добавили тази функция:
Все пак няма опция за избор на параметри от предварително дефиниран падащ списък. Този пример обаче показва, че CircleCI все още е в процес на активно развитие и се опитва да изгради много неща, които Дженкинс вече има.
Планирам да пиша за други липсващи функции в CircleCI, с които свикнах в Jenkins и как ги преодолявам, така че може да искате да останете на линия.
CircleCI SLA
Въпреки че CircleCI може да се хоства самостоятелно, най-значимият му плюс е, че е инструмент за софтуер като услуга (SaaS), който поема цялата тежка работа за настройка, управление и мащабиране. С Jenkins вие сте отговорни за времето на работа на вашата услуга, но с CircleCI можете да седнете и да разчитате на Споразумението за слой на услугата (SLA).
Дори след една година опит с CircleCI не изпитах пълен престой. Често виждам този малък маркер в долния ляв ъгъл на потребителския им интерфейс.
Понякога това означава, че компилациите ми са по-бавни от обикновено, а понякога не виждам никаква разлика. Трябва да призная, че ми харесва, че CircleCI винаги ясно показва статуса си и не се опитва да се преструва, че нищо не се случва, както някои други облачни доставчици.
Потребителски интерфейс
Jenkins има много по-функционален интерфейс от CircleCI. Понякога дори е прекалено. Можете да настроите целия тръбопровод с декларативен скрипт синтаксис на Groovy или без един ред код, като просто щракнете върху множество съветници за потребителски интерфейс. Намирам, че има удобни функции, особено за начинаещи.
CircleCI има по-прост, добре изглеждащ интерфейс (лични предпочитания) и не можете да правите толкова много тук. Настройката на декларативния тръбопровод се извършва в .circleci/config.yml файлове с помощта на Yaml синтаксис. Първоначално бях раздразнен от липсата на функционалност на потребителския интерфейс, но осъзнах, че е направено нарочно, за да се наложи принципът „Инфраструктура като код“.
Сравнение рамо до рамо
Както Jenkins, така и CircleCI могат да се използват като CI/CD инструменти, но:
Дженинс
- е сървър за автоматизация, който може да се използва за непрекъсната интеграция и непрекъсната доставка
- е самостоятелно хоствано решение, което означава повече караница, но и повече контрол за проекти, свързани със сигурността
- има отворен код и лиценз на MIT, което означава, че е безплатен, но все пак трябва да платите за хостинг доставчик
- има много добавки и може да бъде значително персонализиран
- поддържа както тръбопроводни скриптове, така и настройка на работен поток на потребителския интерфейс
- може лесно да се използва локално безплатно както на Windows, така и на macOS
CircleCI
- е платформа за непрекъсната интеграция и непрекъсната доставка
- може да се използва като самостоятелно хоствано решение, но по-популярно като SasS инструмент
- има безплатно ниво и няколко абонаментни плана, така че да мащабирате с времето
- не поддържа плъгини, следователно има минимално персонализиране. Вместо това има „кълба“, които не са повече от разширения на тръбопроводни скриптове
- поддържа само тръбопроводни скриптове и ограничения върху принципа „инфраструктура като код“.
- може лесно да се използва както на Windows, така и на macOS в уеб браузър и с безплатно ниво
- е по-ясен от Дженкинс, следователно по-лесен за започване на работа
Резюме
Може би това не е задоволителен отговор, но ако ме попитате дали Jenkins е по-добър от CircleCI, бих казал, че зависи, тъй като те наистина са различни.
Въпреки че виждам някои недостатъци във функционалността на CircleCI в сравнение с Jenkins, не беше трудно да направя превключване. Настоящият ми екип няма специализирани DevOps, които да се грижат за цялата инфраструктура, и сме добре да запазим колкото е възможно повече в облака, за да мащабираме и да се движим бързо.
Като се има предвид горното, CircleCI е идеалното решение за нас. Преди това работих върху по-корпоративни, дълготрайни проекти със строги изисквания за сигурност и персонализиране, където Jenkins беше почти единственият ни вариант.
Нямах възможност да работя много с други популярни инструменти на пазара, така че не мога да кажа дали CircleCI или Jenkins са по-добри или по-лоши от TravisCI, TeamCity или GitLab. Ще съм благодарен, ако някой с практически опит добави нещо за това в коментарите.
