Непрерывная интеграция и выпуск системы платформы электронной коммерции с супер-трафиком

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

Самый ранний язык разработки — PHP, самая популярная среда выполнения с открытым исходным кодом — LNMP, а управление кодом — SVN.

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

В 2014 году структура нашего бизнеса была скорректирована, и мы создали собственную торговую платформу.

Языком разработки стал JAVA, операционная среда — TOMCAT, а управление кодом — GIT.

После того, как бизнес-система была изменена на JAVA, она также создает дополнительные проблемы для системы публикации. Существует большая разница между публикацией JAVA и публикацией PHP, поэтому мы создали систему публикации JAVA.

Система публикации также была изменена на StarkPlus, которая должна поддерживать больше типов публикаций, режимов публикации и дополнительных функций публикации.

Особенность издательской системы в том, что она поддерживает множество типов, включая JAVA, C++, NodeJS, PHP, Golang, Css_js и сторонние библиотеки.

Существует также множество стратегий публикации, включая пакетную публикацию, групповую публикацию, потоковую публикацию, автоматическую публикацию и пользовательскую публикацию.

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

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

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

В настоящее время Docker является очень популярным контейнером, у нас также есть несколько приложений на Docker, и нам нужно сделать некоторую поддержку Docker. Он также поддерживает смешанные выпуски Docker и KBM.

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

В первую очередь необходимо стандартизировать базовое ПО и конфигурацию.ОС, JDK, tomcat, nginx и т. д. предоставляют набор наиболее стандартной среды для эксплуатации и обслуживания, и все приложения запускаются в одной среде.

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

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

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

На приведенном выше рисунке показана зависимость нашей системы публикации. Круг внутри — ее основная зависимость. CMDB управляет сервером, центр конфигурации управляет конфигурацией приложения, а OpsAgent развертывает агент на каждой машине для выполнения некоторых постоянных задач на сервер.операция. Gitlab занимается управлением кодом, а процессный движок используется для утверждения контента.

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

Архитектура системы публикации очень проста, в основном состоит из двух частей, одна из которых представляет собой внешний интерфейс JAVA, который используется для управления страницами и процессами. Следующий представляет собой набор рабочих процессов, написанных на Pathon для выполнения определенных операций, таких как создание кода, слияние и развертывание. Посередине MQ используется для очереди задач и разделения, и они передаются через БД.

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

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

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

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

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

Методы построения разных типов приложений различаются, и построение основано на объединенной ветке Release.Например, JAVA, C++, GOLANG и NODEJS собираются в Docker-контейнере, и после завершения построения будет вывод.

Каждое приложение имеет URL проверки работоспособности: /status

При доступе к /status проверьте основные зависимости (БД, кеш, зависимые приложения) и прогрейте данные.

Если выполнение выполнено успешно, возвращается "SUCCESS", а остальные условия - сбои.

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

Регулярный экстренный выпуск осуществляется по пятницам и выходным и утверждается R&D;

Праздники, такие как официальные праздники, закрытие сетей операторами и т. д., также подлежат утверждению НИОКР;

В особые периоды, такие как крупные рекламные акции, групповые пресс-конференции и т. д., выпуск теоретически не допускается. Если выпуск требуется, он должен быть одобрен техническим директором.

Глубокая интеграция системы выпуска и системы управления проектами (PMO), требования и проекты могут быть созданы и связаны с изменениями. Об изменениях можно сообщать в систему PMO для обновления требований и статуса проекта после выпуска изменений, чтобы можно было четко определить цель каждого выпуска.

Одно и то же приложение имеет разную конфигурацию в разных компьютерных залах, и сервисы, предоставляемые в разных группах, тоже разные.

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

Обнаружение пакетов Jar и Diff

Обнаружение конфликта пакетов Jar: конфликты пакетов Jar могут вызывать необъяснимые проблемы, и их трудно устранить.

Обнаружение пакетов снэпшотов: версии снэпшотов часто обновляются и неконтролируемы.

Ограничения версии пакета Jar: нельзя использовать устаревшие версии и версии с ошибками.

Jar Package Diff: просмотрите разницу в jar-пакете между этой версией выпуска и базовой версией.

Сканирование внешнего интерфейса: проверка качества кода внешнего интерфейса для выпуска css_js;

Сканирование безопасности: статический анализ безопасности java-кода;

Интеграционное тестирование: модульное тестирование и тестирование интерфейса выполняются одновременно с выпуском предварительной версии среды;

Мониторинг производительности и стресс-тестирование: проведите стресс-тестирование производительности на бета-машинах после выпуска онлайн-бета-версии.

Вот и все на сегодняшнем обмене, спасибо всем!