Как остановить push с ошибками компиляции?

#javascript #amazon-web-services #server #devops #githooks

#javascript #amazon-веб-сервисы #сервер #devops #githooks

Вопрос:

Недавно я отправил ошибку кода (Javascript-использовал const вместо let ) на сервер, и администратор сказал, что это помешало другим разработчикам продвигать свой код? На других сайтах / местах работы я уверен, что делал это раньше, но в файле журнала просто сообщалось «ошибка сборки», и обновление было отклонено.

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

Тот факт, что сервер не обновлялся до того, как я нажал (как сообщали другие разработчики), показывает мне, что моя синтаксическая ошибка не вызвала проблемы с тем, что сервер не обновлялся с помощью нажатого кода.

Помогите! они обвиняют меня в проблеме, которая была на сервере целую неделю до моей «синтаксической ошибки»!

Любые ответы других разработчиков и разработчиков AWS будут с благодарностью получены..

Разве обычно не существует кода подключения сервера, чтобы отправленный код отклонялся и не наносил ущерб серверному приложению?

Комментарии:

1. ДА. Ваш конвейер CI / CD должен начать с попытки собрать проверенный вами код, затем выполнить модульные тесты и интеграционные тесты на нем, и только после этого развернуть его, если он прошел успешно. Но вы все равно не должны проверять код в своей производственной ветке. Весь код должен быть написан в новой ветке, чтобы, когда происходят подобные вещи, это не влияло на производство или даже на UAT.

2. Спасибо, капитан. Сервер не отвечал на push-запросы в коде, который прошел все проверки на конвейере CI / CD любым разработчиком в течение почти 2 недель. Мой push был в порядке, но я выполнил поспешный 2-й push с инструкцией протоколирования, чтобы проверить, выполняет ли промежуточный сервер мой код. Спасибо за ваш код «Ваш конвейер CI / CD должен начать пытаться создать код»..

Ответ №1:

Это вина DevOps (или того, кто отвечает за DevOps) за то, что он не обеспечивает использование ветвей и запросов на извлечение.

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

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

ОБНОВЛЕНИЕ: если вы используете Git, позвольте мне предложить также установить Git Flow на вашей рабочей станции. Он стандартизирует способы исправления ошибок и работы функций и упрощает управление филиалами.

Комментарии:

1. Я должен добавить, что «запрос на извлечение» даже не нужно выполнять в Git. другой разработчик может просто «вытащить» вашу ветку на свой локальный компьютер и попытаться запустить ее и протестировать функцию, над которой вы работали. Если он делает то, что должен был, они могут показать большие пальцы, и кто-то может объединить изменения в ветку разработки, а оттуда в производство.

Ответ №2:

githooks — необязательное решение для этого. Другой вариант — применить CI / CD для вашего проекта, любые сбои при сборке кода, проверке на соответствие, модульные тесты могут вызвать для вас электронное письмо с предупреждением. Вы можете обсудить с командой эти два варианта.