Здравствуйте.
Методология хайповая. На этой волне в компании начали рассматривать варианты полного перехода на феншуй от CI/CD.
Я только начал изучать материал и столкнулся сразу с несколькими противоречиями. Поясню:

С одной стороны пишут, что в CI/CD необходимо по максимуму автоматизировать все процессы от стадии коммита в репозиторий до стадии доставки продукта до заказчика. Как я понимаю, тестирование - это одна из неотъемлемых частей CI/CD?! Так вот пишут в интернетах, что тестирование может быть и ручным! т.е. я понимаю, что покрыв Unit-тестами какой то важный модуль/модули можно добиться автоматизации - тест прошел - двигаемся дальше, не прошел - допиливаем код.

А как быть если Unit-тесты отработали на ок, и нужно тестировать весь продукт полностью. Предположим даём нагрузку - и в результате, что-то падает. Т.е. такой продукт/модуль продукта уже нельзя доставлять заказчику!? А если CI/CD проповедует полную автоматизацию, то как автоматизировать результаты нагрузочного тестирования? Ведь человек принимает решение - выкатывать апдейт клиенту или не выкатывать?!

Возможно я что-то не так понял, но моё представление о CI/CD - это один раз хорошенько помучиться, а потом (очень утрированно) один коммит - одно исправление у клиента(заказчика)? Разве не так?

Alexey Tomin,

Алексей, спасибо за ответ, если не возражаете, хочу продолжить дискуссию. Накопилось много вопросов, и не на все есть внятные пояснения.

Один из таких вопросов: Без каких "компонент" внедрение CI/CD невозможно?

Правильно ли что должны быть обязательно:

-Система версионного контроля
-Build-сервер
-Этап тестирования
-Анализатор кода
-Хранилище артефактов
-Контейнеризация
-Система управления контейнерами
-Мониторинг
?

Читал много разных статей, в итоге "нарисовалась" такая картина. Если я ошибаюсь - не вопрос, с удовольствием приму правильный ответ от знающих людей. Вот Вы бы что включили в состав CI/CD?

hVostt,

Да я, как Вы сказали, и "составляю списки", чтобы попробовать (попробовать!) загнать несколько продуктов разрабатываемые под разными стеками, под единый, если так можно выразиться "Стандарт".

Только "стандарт" будет выражаться не в используемых технологиях, а подходе к разработке, интеграции и доставке продукта до конечного клиента.

Т.е. с одной стороны: хочется унифицировать этот процесс, чтобы в определённый момент времени, показав "график прогресса разработки" топ-менеджеру, было понятно, как продвигаются дела по указанному продукту, с другой стороны не хочется нести денежные траты, только потому, что (утрирую) в одном отделе используют TeamCity (по историческим причинам) а в другом - бесплатный Jenkins.
И может быть имеет смысл обоих перевести на Jenkins, а денежную разницу от перехода использовать для чего то другого.

Про задачу, Вы мне твердите уже раз третий наверно. Это к слову о голове и граблях.
Я же пытаюсь разными словами донести Вам мысль, что я НЕ ПРИВЯЗАН к технологиям (ne privyazan k technologiyam). Цель одна - постараться выработать единый стандарт или несколько стандартов разработки, накатывания обновлений,
взаимодействия с командой разработчиков.

В организации полный винегрет стеков, кто на что горазд. Да, не все они бесплатны, возможно по этой причине руководство приняло решение навести порядок. Это в своём роде некая "ревизия", возможно, кто-то засиделся на старом подходе или стеке, и внедряет свой продукт слишком долго и болезненно.

Какую задачу Вы решаете, когда покупаете третью пару летних кроссовок или штанов в сезоне?

Вы всё правильно говорите. Я с этого и начал. Пытаюсь понять и зафиксировать текущий "расклад" ситуации в огранизации. Говорю с людьми, фиксирую проблемы с которыми они сталкиваются. Но у людей, на законных основаниях, возникает вопрос, а зачем мне это всё нужно? Чтобы сориентировать "для чего" и "куда" приходится показывать "свет в конце туннеля" в виде CI/CD. И, что интересно, ни у кого не возникает отторжения, никто не пытается моментально переубедить в бесполезности подходов CICD.

Я уже несколько раз переделывал документ, который пополняется в результате бесед с тимлидами и рядовыми разработчиками, и думаю, переделаю его ещё не раз и не два. CICD я использую как ориентир, возможно мы к нему и не перейдем и будет нечто среднее, между CICD и чем то ещё. Повторюсь, что в поиске "стандарта разработки", придет совместное понимание, вещей, которым раньше не уделялось должного внимания.

именно!

Потому, что некоторые покупают кроссовки потому что понравились. Красивые. У них нет жизненно важной необходимости, потому что старые протерлись до дыр или отпала подошва. Просто понравились. В них тупо удобнее. Хотя и старые не развалились и нога в них ок.

Именно по этой же причине, молодежь меняет по 5 штук смартфонов за год (а то и больше) У нового гаджета есть NFC - беру! Что картой расплатиться нельзя что-ли? Какие задачи он решает?

Ну так и есть )) Соглашусь, что в силу своей неопытности в вопросах CI/СD я использую выражения, которые могут совсем не подходить для описания сути вопроса.

Но мне всё таки хочется, нащупать "тело" и "кости" этой методологии, чтобы она не осталась для меня "сферическим конём в вакууме" а имела вполне конкретную практику реализации. Понятно, что для каждой компании она своя, но стоит копнуть глубже, сразу упираюсь в советы типа "Какие задачи?", Средства? - "Всё что потребуется".

Так можно и до абсурда дойти, писать всё в блокноте, компилировать из батника, а в команде иметь два с половиной программиста, которые и тестировщики, и аналитики, и QA и всё на свете. Но это не будет CI/СD - это будет шляпа.

Если бы здесь привели реальные примеры практик реализации полностью раскрывающие CICD, то мне бы, на первое время этого бы хватило.