Комментарии 6
Печально, что в статье, инженеры из X5 Retail и Southbridge по видом CI/CD(процессов) предполагают только инструменты для деплоя.
Скажу за себя — я привык к подходу «меньше теории, больше практики», поэтому да, сделан упор на рабочие инструменты, а не методологию и взаимодействие людей. Мы, кстати, упоминали в разговоре, что CI/CD это не только деплой, но и всяческие проверки кода, в том числе и не только автоматикой. Очень интересно узнать Ваше мнение, каких пунктов не хватило в нашем обсуждении?

CI/CD — это в первую очередь процессы. А уж на чем они сделаны — дело второстепенное.
Кстати, очень интересно, что Gitlab CI внутри себя имеет именно аббревиатуру CI, а не CD. Что намекает на то, что это не инструмент для деплоя, хотя и с определенными ограничениями может быть использован — какая разница — у нас пайплайн и там, и там. Но дьявол в деталях. Пайплайны CD должны быть написаны особым образом, чтобы в случае падения у нас ничего не разметало. А если CI упал… ну, упал и упал — перезапустил.
Ничего не сказано про принцип Shift-to-left, который вообще универсален. Типичная история — про безопасность. Когда мы чего-то разработали и потом внезапно выясняется, что мы НЕ МОЖЕМ это выкатить в продакшен, хотя тесты все проходят, код сам по себе с точки зрение бизнеса и выполняемых функций качественный. Но нет. И поэтому выгодно интегрировать процессы безопасности в CI/CD пайплайн и сразу делать хорошо по всем фронтам.

Кстати, очень интересно, что Gitlab CI внутри себя имеет именно аббревиатуру CI, а не CD.

Мне тоже это долгое время было интересно… И недавно заметил заметил, они уже официально переименовались в GitLab CI/CD.

Они отобрали последний аргумент ) На самом деле в этом есть логика, потому что они же внедрили интеграцию с кубернетесом (плохую, кстати, на мой вкус) и сейчас затаскивают свой вариант GitOps оператора… Поэтому — да, это будет CD, но для куба.
Но специализированное решение вроде Spinnaker им не переплюнуть в любом случае.

В целом, полностью поддерживаю комментарий от gecube ниже, по этому поводу.
Мы, кстати, упоминали в разговоре, что CI/CD это не только деплой, но и всяческие проверки кода, в том числе и не только автоматикой. Очень интересно узнать Ваше мнение, каких пунктов не хватило в нашем обсуждении?
Ну, как то так — www.thoughtworks.com/continuous-integration
У CI вполне есть критерии — разработчики пушат в master/trunk как минимум каждый день, на каждый коммит прогоняются тесты и пр., сломанные билды быстро фиксятся, с CD это всё должно ещё и так же часто выкатываться на прод.
Все проблемы и вопросы, вобщем то, из этого и вытекают, основной и глобальный вопрос конечно в том, как поддерживать культуру разработки на таком уровне, чтобы можно было быстро вносить изменения, пушить в мастер таски которые ещё не готовы ничего не ломая(branch by abstraction, feature toggles и пр.), успевать делать ревью(или как его не делать, или делать после деплоя), как убеждаться что билд не положит прод, как иметь возможность быстро его откатить(вот где требования к инфраструктуре), как постоянно и быстро решать возникающие технические и процессуальные(сошлюсь снова на комментарий выше) проблемы и пр.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
southbridge.io
Численность
51–100 человек
Дата регистрации

Блог на Хабре