Здравствуйте, Sharov, Вы писали:


S>Еще раз -- как минимум надо знать гит, базовые вещи в нем. Кмк, за аббревиатурой CI\CD это обычно скрывается

Ну так и написали бы, зачем зря воду мутить-то?

Здравствуйте, undo75, Вы писали:

M>>думаю, что имеется в виду наличие некоей автоматики, которая по выполнению ряда условий производит merge из одной ветки [промышленной VCS] в другую, собирает build на build-сервере и куда-то его потом деплоит.
M>>А работа в команде тут при том, что если кто-то что-то не то закоммитит, то нарушит/замедлит CI.
M>>Такое есть не везде/не в полном объеме.
U>а так не везде?
Далеко не везде.

BFE>Далеко не везде.

ну на всяких заводах понятно — бардак. но где все относительно новое — разве не везде?

Здравствуйте, T4r4sB, Вы писали:

TB>Ну есть какая-то автоматика, с которой никто твой реквест даже смотреть не будет если есть сломанные тесты. А для прогера в чем специфика? Просто пиши код и не ломай старое поведение — смысл тот же, только легче проверяется
Так кто настраивает CI систему? Кто добавляет поддержку новых библиотек и платформ в ней и т.д.

Здравствуйте, Skorodum, Вы писали:

S>Так кто настраивает CI систему? Кто добавляет поддержку новых библиотек и платформ в ней и т.д.

Девопс

Здравствуйте, m2user, Вы писали:

M>Такое есть не везде/не в полном объеме.
M>Вдруг ты всю жизнь shareware в одиночку писал и т.п.

Даже если в одиночку всю жизнь писал, для программиста всё знание о CI/CD заключается в:

каждый коммит или pull/merge request запускает CI (процесс верификации, сборки и тестирования) и, возможно, CD (процесс разворачивания в каком-то тестовом окружении, актуально для железяк и веба).

Это девопсам нужно всю эту кухню создавать каждый раз с нуля в новой компании (или разбираться в существующих скриптах), а для программиста CI/CD — чёрный ящик. Всё, что нужно знать, это то, где прочитать инструкцию о процессах разработки данной компании: что запускает этот чёрный ящик и где смотрить результаты (ошибки сборки, отчёты тестов, и тд).