почему
В апреле этого года я устроился на вторую работу, привык к шелковистому опыту своего старого клуба и вдруг почувствовал, что попал в "первобытное общество". Во-первых, это длинная статья, в которой в основном представлены некоторые мои мысли о процессе автоматической публикации.
Цитируя ЮбоЭволюция модели веб-исследованийНапример, сейчас мы живем в эпоху Web1.0:
- Связывание внешнего и внутреннего кода
- Среда Java слишком сложна для внешнего интерфейса
- Отсутствие инструментов и спецификаций, код сложно поддерживать
- Встроенный код: встроенный html js, встроенная логика java jsp
- Код уровня страницы, наложение кода: более 2000 строк js в одном файле по желанию
- Ручной выпуск, неприятные изменения
Когда это происходит, первое, что приходит на ум, этоПереднее и заднее разделение. Однако, учитывая текущую ситуацию с кадрами и техническими резервами, прямой переход на full-stack разработку на базе NodeJS будет иметь большое сопротивление и длительный цикл, и родить его, скорее всего, будет сложно.
и мы должны сначала解决的问题Да:
- Четкие обязанности по фронтенду и бэкэнду
前后端物理分离
-
- Страницы, требующие SEO: соответствующие шаблоны по-прежнему размещаются в бэкэнде, но бизнес-логика будет сокращена.
Цель
Мы сначала смотрим на процесс разработки и выпуска, чтобы увидеть, какой конечный результат мы хотим, а затем анализируем, как достичь этой цели.
Процесс развития
- Проект следует процессу: обзор требований -> визуальный обзор -> соглашение об интерфейсе -> оценка требований -> обзор TC -> параллельная независимая разработка -> совместная отладка -> тестирование -> выпуск.
- Четкие задачи до и после процесса разработки, независимая параллельная разработка
Процесс публикации
- Процесс релиза должен строго соблюдаться, а тест и обзор могут быть запущены только после прохождения теста.
- Для всего процесса нужно просто выдать инструкции, а все вещи по компиляции, сборке и синхронизации сервера передаются задаче (позже мы упомянем, что нужно сделать в задаче релиза)
Что нужно сделать, чтобы отделить
- разделение кода Используйте git для управления версиями кода, подавайте заявки на новые приложения для поддержки внешнего кода.
- Используйте веб-пакет для управления модулями После разделения кода мы можем использовать текущие основные интерфейсные фреймворки и инструменты для создания удобной среды разработки и процесса.
- После разделения, запроса внутреннего интерфейса, совместной отладки, отладки, все нужно установить прокси
- Автоматизированная публикация
- конфигурация сервера Подумайте, как развернуть интерфейсный код
Автоматизированная публикация
Во-первых, давайте поговорим об общем процессе публикации:
- отправка кода
- сборка пакета
- Текущий файл сервера резервного копирования - откат с помощью
- Синхронизировать результаты сборки с каталогом сервера
- Слияние кода с Мастером — убедитесь, что последующий код актуален.
Это какая-то чисто ручная работа.Чтобы обеспечить порядок и правильность шагов, легко вызвать проблемы, и нет записи или журнала, поэтому обычно делайте контроль разрешений, и если вы публикуете общий запрос, вы должны найти соответствующий одноклассник, чтобы опубликовать его, и это проблематично изменить.
Так что релиз должен自动化, автоматическая публикация внешнего интерфейса онлайн-поиска, большинство результатовJenkins+ Гитхук (Автоматическое развертывание внешнего интерфейса Jenkins + github)
Его основной принцип в основном заключается в
- Отправьте код, чтобы активировать push-событие веб-перехватчика
- Jenkins прослушивает пост-запрос webhook, выполняет сборку скрипта, синхронизирует сервер (в основном зависит от скрипта)
Но если я хочу посмотреть запись релиза, откатиться и проконтролировать процесс релиза, то похоже Jenkins ничем не поможет (может есть соответствующий плагин, я в него не вникал)
Те же сценарии выпуска можно выполнить с узлом, поэтому мы намерены использовать для написания узла发布集成服务Вместо Дженкинса это может сделать более тонкий контроль:
- Отправка кода не означает выпуск, это может быть просто резервная копия кода, а выдача инструкций означает выпуск.
- Записи о выпуске могут быть созданы и отображены на платформе выпуска для удобного просмотра и отката.
- Обратная связь в режиме реального времени и информация о процессе выпуска
- Контролируйте процесс выпуска, добавляйте аудит, CodeReview и делайте выпуск более безопасным
Таким образом, наша автоматизация выпуска в основном делает три вещи:
- CLI: Позвольте студентам знакомы с командной строкой, после того, как Git push сможет вводить выданные команды (создать новую публикацию, выпуск)
- Издательская платформа: просмотр записи о выпуске, выпуск, аудит, просмотр журнала, откат
- Интегрированный издательский сервис: выполнение сценариев выпуска, синхронизация серверов, резервное копирование недавно выпущенных файлов (быстрый откат), обратная связь с информацией о выпуске, контроль выпусков.
CLI
Интерфейс командной строки представляет собой набор стандартных команд жизненного цикла разработки интерфейса, который выполняет различные задачи процесса разработки интерфейса с помощью нескольких подкоманд, в том числе:
- в этом:Инициализировать структуру проекта, похожий на
vue-cli init, но начать работу относительно просто (поскольку размер временного бизнеса не требует частого создания новых проектов) - Разработчик:Запустить службу разработки и отладки,в основном
npm run dev, не суть - публиковать:Опубликовать код проекта, после выполнения публикации будет выполнена задача публикации кода в соответствующей ветке разработки в репозитории проекта. Код, созданный в облаке, в конечном итоге будет выпущен в соответствующую среду (SIT, UAT, производство).
Справочник разработчиков по CLI -Как разработать CLI с Nodeв основном:commander + inquirer
С тех пор это стало делом порядка
Издательская платформа
Платформа публикации предлагает больше функциональных возможностей, чем интерфейс командной строки:
- Посмотреть историю выпусков
- Просмотр журналов
- откат
- Управление выпуском и контроль
Интегрированный издательский сервис
Что касается главного события, вот несколько концепций
Процесс публикации
Зачем создавать релизы в облаке
Прежде всего, окончательный код, развернутый на сервере, должен быть синхронизирован с файлами на сервере с помощью таких команд, как scp, потому чтоПроблема с разрешениями, единое управление и контроль через облако более надежны.
Кроме того, машинная среда у всех разная.Возможно успешно выполнить сборку в A, но потерпеть неудачу в B (например, A добавляет зависимость, но не сохраняет зависимости), поэтому для компиляции и сборки в унифицированной среде вы можетеИзбегайте проблем со сборкой из-за экологических проблем.
Наконец, нужно место, чтобы пойтиЕдиное управление записями релизов, во избежание конфликтов публикации, записывайте журналы публикации и упрощайте операции отката.
управление филиалом
Каждый извлекает и разрабатывает пользовательскую ветку на основе Мастера и, наконец, автоматически синхронизирует ее с веткой Мастер через выпуск, чтобы убедиться, что разработка основана на последнем онлайн-коде, и в то же время проверка на конфликт выполняется во время релиз для обеспечения безопасности релиза.
Изменения ветки процесса выпуска следующие:
Управление выпуском
В течение всего процесса выпуска наш код должен проходить ежедневные и предварительные тесты, прежде чем он сможет, наконец, выйти в сеть.Этот процесс требует, чтобы соответствующий сервер был занят и стабилен, и необходимо избежать ситуации, которую публикуют и освещают другие студенты, поэтому мы используем MongoDB для поддержки发布记录, для достижения контроля выпуска и контроля процесса
снять контрольКогда проект выпускается в указанной среде выпуска, среда занята, а другие проекты выпускают приглашение有其他项目发布，联系对应的发布同学, две стороны решают, отказаться ли от выпуска в зависимости от важности и позволить более поздним проектам подняться первым.
Контроль над процессомЧтобы убедиться, что окончательный онлайн-код работает правильно, весь процесс требует тестирования и проверки кода, которые должны пройти测试、审核перейти к следующему этапу
Опубликовать отзыв
Сценарий публикации должен выполнять ряд процессов, упомянутых выше, для которых требуется процесс ожидания.Нам необходимо предоставить отзыв о публикации (процесс публикации, успех или нет) публикующим студентам в режиме реального времени и сохранить соответствующую информацию в журнале. Таким образом, процесс публикации устанавливает ссылку на сокет через soket.io, и о любых изменениях процесса в интегрированной службе публикации будет сообщено.
сервер синхронизации
Сервер синхронизации может использовать команду scp или rsync, см. введение и разницу между ними.это
Эти две команды синхронизируются через ssh, и обе требуют ввода пароля после выполнения команды, поэтому необходимоСотрудничайте с ожидаемой автоматической синхронизацией
В итоге был выбран весь сервис: express + socket.io + mongodb, который здесь описывать не буду.