Разумно ли просить инженера-программиста сделать CI вручную для компании?

В целом разумно? Это необходимо. Что-то, что вы хотите взять на себя? Под вопросом.

Это сочетание ручного контроля качества, DevOps, работы администратора и попытки изменить культуру, в которой разработчики совершают безрассудные усилия. Никто не заботится о качестве до такой степени, что они не могут даже сгенерировать сборку, поэтому они назначили вас цифровым уборщиком для ее очистки.

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

Такое ощущение, что это не имеет ничего общего с процессом разработки программного обеспечения.

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

Вот что вам нужно решить:

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

Если вы можете легко уйти без каких-либо последствий, просто проявите некомпетентность в этом, и вам назначат кого-то другого. Опыт в этом будет означать, что они заставят вас делать это больше, и вы потратите еще меньше времени на разработку. Потратьте время на очистку старого доброго резюме.

Считаете ли вы, что разумно просить об этом инженера-программиста?

Да. Вас попросили управлять и поддерживать качество программного обеспечения, оно полностью соответствует тому, что ожидается от разработчика, даже если это неблагодарно.

Вы когда-нибудь встречали нечто подобное?

Много раз. И что я сделал, так это взял на себя ответственность за качество и внедрил автоматические проверки, которые будут кричать на владельца неработающего кода. Это ваш шанс проявить себя и вместо того, чтобы жаловаться на отсутствие CI, на самом деле внедрить его.

Такие вещи, как непрерывная интеграция, практически невозможны.

Я не куплюсь на это ни на секунду. Если человек может просматривать журналы и отправлять электронные письма людям, то и сценарий может. Начните с малого, с чего-то очень простого, например, линтинга каждого коммита или просто проверки того, собирается ли он, и наращивайте оттуда. Это процесс, и, очевидно, вы теперь ИТ, чтобы начать его.

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

Это также ваш шанс начать внедрение среды CI. Мои предложения:

• начните с настройки сервера сборки; если нет реальной машины для сборки, вы можете начать на своей собственной машине. Я рекомендую www.jenkins.io, так как есть плагины для всего, и вы найдете учебник или инструкции почти для каждой задачи.

• постепенно добавляйте дополнительные функции на сервер сборки, например модульные или интеграционные тесты, покрытие кода, анализ кода, упаковка/развертывание и т. д.

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

Во-первых, в теории это разумно спросить. Другими словами, кто -то должен нести ответственность за обеспечение качества кода . В идеале, конечно, это должны быть обязанности всех , но, похоже, ваша компания облажалась, вот и рассчитываются с «кем-то». В этом случае вы «кто-то», и именно поэтому вас выбрали.

Мой вопрос: почему CI невозможна для вашей компании? По крайней мере, что, если вы напишете (или попросите других написать) модульные тесты для их кода, чтобы убедиться, что их код правильный, и автоматически запустите эти тесты перед развертыванием? Есть ли у вас один человек (или группа людей размером O(1) относительно вашей организации размером O(n)), ответственный за развертывание? Этим людям можно поручить запустить модульные тесты перед развертыванием и отклонить сборку, если тесты не пройдены. Это похоже на выполнение CI вручную, и это лучше, чем ничего (это определенно далеко от идеала, но это лучше, чем то, что у вас есть сейчас).

Насколько велика ваша власть в этой компании и насколько руководство готово выслушивать опасения разработчиков? Если бы вы пришли к руководству и сказали: «Это неустойчиво, слишком много проблем, и никто их не исправляет, наше программное обеспечение постоянно ломается», что бы они сказали? Не могли бы вы расставить приоритеты, по крайней мере, исправить существующие проблемы и добавить модульные тесты, по крайней мере, для этих исправлений, чтобы убедиться, что они не присутствуют в регрессии? И можете ли вы привлечь руководство к наказанию разработчиков, которые отказываются придерживаться этой практики? Вы должны встретиться с руководством (или, по крайней мере, с человеком, который предлагает вам взять на себя эту роль) и задать им эти вопросы.

Что касается управления кодом, вы сказали, что не используете Git, но у вас есть репозиторий. Есть много компаний, которые используют альтернативы Git, такие как Subversion, и прекрасно работают. Если у вас нет веской причины использовать именно Git, это не особенно важно.

Вы новый сотрудник? Если это так, то это может быть обряд посвящения или форма дедовщины, так сказать. Вы получаете самую низкую работу и продвигаетесь вверх, если останетесь.

Моя мысль: это не что-то большое. Я бы просто сказал, что это, вероятно, высокая позиция, если они заставят вас выполнять эту задачу. Скорее всего, вы оказались в таком положении, потому что другой парень хочет делать «крутые вещи».

Что, я думаю, тебе следует сделать: уйти сейчас, пока ты впереди. Я не уверен, почему люди на этом форуме советуют людям оставаться и пытаться что-то изменить. Мы не работаем на НАСА, решая мировые проблемы или медицинские устройства. Есть множество других профессий, которые предлагают сложные роли, не требующие убеждения людей делать что-то правильно. Спросите любого члена АА, каков первый шаг к решению проблемы алкогольного опьянения, и он скажет вам, что вы должны признать, что у вас есть проблема и вам нужно ее решить. Если на вашем рабочем месте не хотят признавать, что у них есть проблема, и упрямо ее видят, то вы точно не станете «тем парнем», который это сделал. Вам не нужно работать над новейшей, супер крутой структурой, и вам не нужен какой-то отличный процесс CI для выпуска продуктов. Люди делают это с 80-х годов с большим успехом, и не требуется несколько дней, чтобы подготовить релиз и выяснить, кто что сделал. Были ночные сборки за десятилетия до GIT или чего-то еще, что мы видим сегодня. Простая ветвь или тегирование прекрасно подходят для большинства выпусков SVN. Если ваше рабочее место настолько дезорганизовано, что не может этого сделать, я бы сказал, что не стоит оставаться на месте.

Вы вряд ли получите много сочувствия от этой группы. Многие из нас начинали еще до того, как CI стала чем-то особенным. Наш «CI» состоял из двух парней, вручную проводивших тесты в течение 3 недель. Многие из нас постепенно автоматизировали подобные проблемы в течение многих лет. Это можно сделать, и это можно сделать на низовом уровне, но это медленный процесс.

Наша небольшая команда настроила собственный CI-сервер еще до того, как у нас появился «официальный». Наш успех в эксперименте вместе с другими командами — это то, как мы смогли убедить руководство профинансировать официальный эксперимент.

У меня был свой личный репозиторий git поверх нашей «экзотической» VCS, когда у нас были проблемы с постоянными неработающими сборками, подобными тому, что вы описываете. Это позволило мне убрать сломанные изменения из моей стабильной ветки, когда мне нужно было выполнить работу. Мой успех и успех других в такого рода экспериментах — одна из причин, по которой мы сегодня официально используем git.

Сейчас дела обстоят намного лучше, но более сложные изменения, такие как обновления зависимостей и ненадежные тесты, теперь ломают сборку, и люди до сих пор не всегда понимают, когда это их вина. Я по-прежнему регулярно и добровольно провожу день, чтобы быть «полицией сборки», чтобы помочь моей команде получить чистую сборку, чтобы закончить наши функции поверх, даже когда я ищу способы улучшить автоматизацию, чтобы контроль не был таким необходимым. Почти каждый с любым стажем работы делает. Мы не думаем, что это ниже нашего достоинства, и вы тоже не должны.

• Да, встречал что-то подобное
• Я предполагаю, что вы используете другой контроль версий, чем git
• Мой совет: меняйте постепенно. Сначала разберитесь с худшим. Как правило, людей можно убедить измениться