опыт работы в команде с использованием промышленной системы контроля версий, CI/CD?
где бы не работал — вроде было само собой разумеющимся и никак не выделялось из процесса
Здравствуйте, undo75, Вы писали:
U>опыт работы в команде с использованием промышленной системы контроля версий, CI/CD? U>где бы не работал — вроде было само собой разумеющимся и никак не выделялось из процесса
А опиши свои практики CI/CD, что было именно у тебя?
K>А опиши свои практики CI/CD, что было именно у тебя?
дак в том и прикол, что это было самотеком и без каких-то там конкретных практик. поэтому и вопрос. не требовалось менять подход к работе. все как бы само собой. там где это тоже было. поэтому вот и не понимаю что этим хотят сказать. вроде естественный процесс.
Здравствуйте, undo75, Вы писали:
U>дак в том и прикол, что это было самотеком и без каких-то там конкретных практик. поэтому и вопрос.ественный процесс.
Ясно, ты не подходишь под это требование.
U>>дак в том и прикол, что это было самотеком и без каких-то там конкретных практик. поэтому и вопрос.ественный процесс. K>Ясно, ты не подходишь под это требование.
Здравствуйте, T4r4sB, Вы писали:
TB>Это вопрос на прогера или на девопса? Если на прогера то суть требования не понятна
Не у всех есть опыт работы с ci/cd. Те же начинающие погромисты после вуза. Как бы тоже своя специфика и можно долго привыкать и ломать дрова по началу, поэтому это один из критериев отбора.
Здравствуйте, Sharov, Вы писали:
S>Не у всех есть опыт работы с ci/cd. Те же начинающие погромисты после вуза. Как бы тоже своя специфика и можно долго привыкать и ломать дрова по началу, поэтому это один из критериев отбора.
Не понял, какие дрова? Как прогер (не девопс) может что-то сломать?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, undo75, Вы писали:
U>если несложно разверни мысль
Я тебе задал один простой вопрос, но не получил никакого ответа и рассказа как оно было у тебя, поэтому делаю вывод, что ты ни с CI, ни с CD ты не работал.
U>дак в том и прикол, что это было самотеком и без каких-то там конкретных практик. поэтому и вопрос. не требовалось менять подход к работе. все как бы само собой. там где это тоже было. поэтому вот и не понимаю что этим хотят сказать. вроде естественный процесс.
думаю, что имеется в виду наличие некоей автоматики, которая по выполнению ряда условий производит merge из одной ветки [промышленной VCS] в другую, собирает build на build-сервере и куда-то его потом деплоит.
А работа в команде тут при том, что если кто-то что-то не то закоммитит, то нарушит/замедлит CI.
Такое есть не везде/не в полном объеме.
Вдруг ты всю жизнь shareware в одиночку писал и т.п.
K>Я тебе задал один простой вопрос, но не получил никакого ответа и рассказа как оно было у тебя, поэтому делаю вывод, что ты ни с CI, ни с CD ты не работал.
работал неоднократно, где указывалось это требование. значит или они натрындели или я таки по этому процессу работал. просто недопонимаю что за этим конкретно скрывается. поэтому и попросил развернуть мысль.
определение и расшифровка понятно. что это меняет на практике — не очень понятно. в чем радикальное отличие от поставленного процесса?
M>думаю, что имеется в виду наличие некоей автоматики, которая по выполнению ряда условий производит merge из одной ветки [промышленной VCS] в другую, собирает build на build-сервере и куда-то его потом деплоит. M>А работа в команде тут при том, что если кто-то что-то не то закоммитит, то нарушит/замедлит CI.
M>Такое есть не везде/не в полном объеме. M>Вдруг ты всю жизнь shareware в одиночку писал и т.п.
TB>Не понял, какие дрова? Как прогер (не девопс) может что-то сломать?
вот именно. коммитишь. проходишь ревью. изменения мэрджит специально обученный человек. билд идет на один из тестовых стендов, где работает тестировщик с конкретным билдом. далее мерджится в релиз (в случае техподдержки) или ветку для разработки, которая потом впоследствии мерджится в релиз. от прогера не зависит в этом плане ничего.
Здравствуйте, T4r4sB, Вы писали:
S>>Не у всех есть опыт работы с ci/cd. Те же начинающие погромисты после вуза. Как бы тоже своя специфика и можно долго привыкать и ломать дрова по началу, поэтому это один из критериев отбора. TB>Не понял, какие дрова? Как прогер (не девопс) может что-то сломать?
Здравствуйте, undo75, Вы писали:
U>вот именно. коммитишь. проходишь ревью. изменения мэрджит специально обученный человек. билд идет на один из тестовых стендов, где работает тестировщик с конкретным билдом. далее мерджится в релиз (в случае техподдержки) или ветку для разработки, которая потом впоследствии мерджится в релиз. от прогера не зависит в этом плане ничего.
1) Такие вещи кто-то же настраивает и поддерживает, скорее всего разработчик(и), соотв. некоторые знания необходимы.
2) Процессы могут быть разные, у нас каждый сам мерджит свою задачу, например. Т.е. ряд каких-то манипуляций с гитом
проделывать надо, а не просто пушить код. CI\CD, кмк, процентов на 80 подразумевает знание гита. Остальное -- знание
и настройка соотв. инструментов типа TeamCity, GitLab и т.п.
Ну есть какая-то автоматика, с которой никто твой реквест даже смотреть не будет если есть сломанные тесты. А для прогера в чем специфика? Просто пиши код и не ломай старое поведение — смысл тот же, только легче проверяется
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
S>>+ S>>с гитом чего-нибудь такого навертеть. TB>Ну есть какая-то автоматика, с которой никто твой реквест даже смотреть не будет если есть сломанные тесты. А для прогера в чем специфика? Просто пиши код и не ломай старое поведение — смысл тот же, только легче проверяется
Еще раз -- как минимум надо знать гит, базовые вещи в нем. Кмк, за аббревиатурой CI\CD это обычно скрывается. Либо
явно проговаривается необходимость навыков работы с гит.
Здравствуйте, T4r4sB, Вы писали:
S>>2) Процессы могут быть разные, у нас каждый сам мерджит свою задачу, например. Т.е. ряд каких-то манипуляций с гитом TB>Дык это уже не к CI/CD относится а к работе с системами контроля версий
Так это все вместе сейчас, по сути. Я выше уже ответил.
Здравствуйте, undo75, Вы писали:
M>>думаю, что имеется в виду наличие некоей автоматики, которая по выполнению ряда условий производит merge из одной ветки [промышленной VCS] в другую, собирает build на build-сервере и куда-то его потом деплоит. M>>А работа в команде тут при том, что если кто-то что-то не то закоммитит, то нарушит/замедлит CI. M>>Такое есть не везде/не в полном объеме. U>а так не везде?
Далеко не везде.
Здравствуйте, T4r4sB, Вы писали:
TB>Ну есть какая-то автоматика, с которой никто твой реквест даже смотреть не будет если есть сломанные тесты. А для прогера в чем специфика? Просто пиши код и не ломай старое поведение — смысл тот же, только легче проверяется
Так кто настраивает CI систему? Кто добавляет поддержку новых библиотек и платформ в ней и т.д.
Здравствуйте, m2user, Вы писали:
M>Такое есть не везде/не в полном объеме. M>Вдруг ты всю жизнь shareware в одиночку писал и т.п.
Даже если в одиночку всю жизнь писал, для программиста всё знание о CI/CD заключается в:
каждый коммит или pull/merge request запускает CI (процесс верификации, сборки и тестирования) и, возможно, CD (процесс разворачивания в каком-то тестовом окружении, актуально для железяк и веба).
Это девопсам нужно всю эту кухню создавать каждый раз с нуля в новой компании (или разбираться в существующих скриптах), а для программиста CI/CD — чёрный ящик. Всё, что нужно знать, это то, где прочитать инструкцию о процессах разработки данной компании: что запускает этот чёрный ящик и где смотрить результаты (ошибки сборки, отчёты тестов, и тд).
