задний план

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

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

Не уклоняйтесь от ответственности, некоторые из которых вызваны новым кодом, который мы представили впоследствии. Из-за накопления проекта за последние два года многие проблемы немного сложно вернуть. Хотя sonarqube генерирует отчет каждый раз, когда jenkins строит, мы не использовал его как успешную сборку Жесткий индикатор отказа. Пока сборка успешно проходит тест QA, все в порядке! К черту ворота качества сонара

результат

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

Когда я уже собирался точить пистолет, я понял следующие 3 болевые точки

Многие проблемы, которые может обнаружить Sonar, на самом деле трудно обнаружить при ручном просмотре PR на GitHub.
У некоторых коллег действительно низкий уровень кода, но его сложно найти в искусственном обзоре кода, не мой котел, я сейчас жопу подтираю.
Хотя проблема была устранена быстро, владелец кода не я. У меня могут быть потенциальные новые проблемы, чтобы соответствовать правилу сонара, и проверка с владельцем по одному увеличивает стоимость связи. Кроме того, владелец очень скорее всего уже уволился

думать

囧 думает измениться! Как мы можем улучшить наш процесс разработки? Может ли Sonar анализировать проблемы на этапе разработки кода? Заставить владельца решить проблему перед отправкой кода? Эм! Пришло время внести улучшения в текущий опрометчивый процесс разработки!

старый процесс разработки

Давайте сначала представим текущую инфраструктуру:

Управление источниками через GitHub
Реализовать Code Review через Github Pull Request (раньше я использовал gerrit, но отказался использовать его на том основании, что пользовательский интерфейс был слишком уродливым)
Непрерывная интеграция с Jenkins
Реализовать анализ кода с помощью Sonarqube (только по названию)

Старый процесс:

Когда новая функция временно
Владелец от главного (защищенного) филиала Оформить заказ Разработайте функцию_dev_branch
После завершения разработки отправляется запрос на включение (PR) мастеру слияния.
После того, как технический руководитель проведет проверку кода и утвердит PR, feature_dev_branch объединяется с master.
Слияние запускает Jenkins для автоматической сборки, Jenkins запускает сканирование Sonarqube для создания отчета (только создание отчета)
Если сборка прошла успешно, будет выполнено развертывание пакета и последующие процессы автоматизированного тестирования.
Проведение тестов контроля качества

Улучшенный процесс разработки:

Когда приходит новая функция
Владелец CHECKOUT разработан из Master_Dev_branch
После завершения разработки отправьте запрос на включение (PR) для слияния с мастером.
PR автоматически запускает Jenkins, а Jenkins запускает Sonar для анализа нового кода, отправленного на этот раз.
Sonar пишет отчеты и вопросы в Github PR в виде комментариев и служит жесткой контрольной точкой.
Владелец неоднократно фиксирует PR, пока он не пройдет анализ Sonar.
После того, как технический руководитель проведет проверку кода и утвердит PR, feature_dev_branch объединяется с master.
Слияние запускает Jenkins для автоматической сборки, Jenkins запускает сканирование Sonarqube для создания отчета (только создание отчета)
Если сборка прошла успешно, будет выполнено развертывание пакета и последующие процессы автоматизированного тестирования.
Проведение тестов контроля качества

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

Ух ты! ! ! Так круто!

Следуйте за мной шаг за шагом, чтобы завершить настройку Jenkins и Sonar

Какой? Ты даже не знаешь, кто такой Дженкинс? ! Тогда какое у вас сердце, чтобы оптимизировать процесс разработки, хорошо двигать кирпичи и писать свои ошибки! Кашель кашель! Предлагаю переслать эту статью коллеге, отвечающему за devops, пригласить его на ужин и пусть он поможет с настройкой.

Его роль заключается в создании веб-перехватчика между Jenkins и GitHub, и аналогичные PR могут автоматически запускать сборку Jenkins.

Немного настройте этот плагин, там, где нарисована красная линия, очень важно

Дженкинсу также нужен плагин под названием SonarQube Scanner.

Его роль состоит в том, чтобы позволить Дженкинсу инициировать анализ Сонара.

Немного настройте этот плагин, там, где нарисована красная линия, очень важно

Никогда не слышали о Сонаре? У вас нет готового сервера Sonar? Тогда приглашайте разработчиков на ужин...

В Sonarqube (обратите внимание, что это в Sonarqube, а не в Jenkins) вам также необходимо установить плагин с именем Github.

Его функция состоит в том, чтобы написать сгенерированный отчет и выдать анализ обратно в PR Github в виде комментариев после того, как Sonar обнаружит его.

Немного настройте этот плагин, там, где нарисована красная линия, очень важно

Следующим шагом является настройка проекта Jenkins.

Не много ерунды, только конфигурация клавиш, красная линия очень важна

Вы можете отметить этот пункт в Advanced (хотя это опасно), потому что наш Github является корпоративной версией, поэтому люди, которые могут отправить PR, имеют контроль разрешений.Если вы используете код управления github официального сайта, пожалуйста, используйте эту опцию с осторожностью. .Рекомендуется использовать черный и белый списки для управления условиями срабатывания.

Ниже приведена очень важная конфигурация Sonar.Обратите внимание, что в режиме анализа можно выбрать только предварительный просмотр, а режим предварительного просмотра фактически не будет генерировать отчет о Sonar.

напиши в конце

Установка Jenkins, установка Sonar и т. д., я не буду помещать ссылку в учебник.Я искал много такого рода дорожных учебников (я лично рекомендую вам установить его с помощью докера) в качестве разработки думаю, что эти основы могут повысить эффективность работы Вам все еще нужно освоить инструменты devops.Это не значит, что только devops будет использовать эти инструменты.Кто не любит быть ленивым, все это хорошие помощники для ленивых.

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