Эффективная и автономная контейнерная платформа доставки = гибкая инженерная концепция x компоненты облачной платформы доставки Qiniu (облачное хранилище + большие данные + контейнерное облако)
С популяризацией концепции DevOps большинство компаний попробовали гибкое управление проектами и добились определенных результатов, но фактический процесс производства кода по-прежнему представляет собой каскадную доставку на основе ролей, которую нельзя разработать, протестировать и развернуть в режиме реального времени. С появлением технологии больших данных каждое предприятие может иметь эффективную и автономную контейнерную платформу доставки.
23 ноября в Чэнду успешно прошла 32-я сессия Qiniu Cloud Architect Practice Day на тему «Практика и совместное использование контейнерных технологий». Ли Цянь (Li Qian), руководитель отдела Qiniu Cloud Engineering Efficiency, поделился с вами замечательным докладом под названием «Платформа Container Cloud Delivery Platform — Real Agile Development/Testing/Deployment» на встрече.
Об авторе:
Ли Цянь успешно руководил внедрением иерархических сред автоматизации тестирования для многих ИТ-компаний и накопил большой практический опыт в области автоматизации. Присоединился к Qiniu в 2014 году, создал систему обеспечения качества Qiniu с нуля, продвигал и улучшал непрерывную поставку и непрерывную интеграцию системы исследований и разработок. Отвечает за контроль качества хранения, обработки данных, прямых трансляций и других продуктов, а также создал первую группу обеспечения качества, которая использует язык go в качестве основы для системы автоматизации.
Ниже приводится отрывок из выступления.
Привет всем, краткое введение, я лично работал в разработке программного обеспечения и тестировании в течение девяти лет, в том числе четыре года опыта технического управления.В 2014 году я присоединился к Qiniu в отделе инженерной эффективности и в настоящее время возглавляю команду из примерно 40 человек для Наша команда по исследованиям и разработкам обеспечивает техническую поддержку и услуги по обеспечению качества, такие как обеспечение качества, управление процессами исследований и разработок и платформа непрерывной доставки. Сегодня я поделюсь с вами практическим опытом контейнерной доставки.
Бизнес-сценарий Qiniu Cloud
Qiniu Cloud была создана в течение 7 лет и теперь имеет 6 линеек продуктов и богатые отраслевые решения, а также некоторые внутренние операции и проекты приватизации. Объем очень большой, по архитектуре мы в основном микросервисы, в основном использующие go, есть и другие языковые стеки, это требует предоставления различных сред компиляции и запуска. Как начинающая компания, наши требования к запуску высоки, и нам нужно быстро реагировать на потребности клиентов.
Отличие больших компаний от малых компаний по услугам Б заключается в том, что маленькие компании могут быстро реагировать, учитывать рациональность спроса и быстро реализовывать их для адаптации к бизнесу заказчика, тогда как в крупных компаниях на это может уйти месяц и даже два месяца. . Наш цикл релизов будет состоять из более чем десятка релизов в день, а также будут релизы вовремя и по запросу. Кроме того, наше сотрудничество также относительно сложно: более 400 разработчиков R&D, которые одновременно пишут код и занимаются онлайн, эксплуатацией и обслуживанием. Некоторые требуют последующего отслеживания и обратной связи, что трудно контролировать с точки зрения качества. Выполнение облачных вычислений, по сути, обеспечивает «водой, электричеством и углем» различные предприятия и предъявляет очень высокие требования к доступности, надежности и качеству. За последние два года мы предоставили комплексные решения для отрасли, которые будут включать более сложные сценарии. Он будет включать в себя комбинированное тестирование нескольких продуктов и услуг, а количество автоматических тестовых случаев также очень велико. Эффективная работа и обеспечение высокого охвата бизнеса — очень сложная задача.
Задача инженерной эффективности
В таком бизнес-сценарии различные задачи суммируются в соответствии с ролями.
Во-первых, разработчики сталкиваются с различными средами компиляции и запуска, самотестирование затруднено, часты слияния веток и не могут быть надежно выпущены. Как инженеры, мы в Qiniu требуем, чтобы каждый был ответственен за свой собственный код, поэтому мы должны предоставить всем удобство тестирования и возможность контролировать качество выпуска кода. Пусть студенты-разработчики смогут сосредоточиться на правильности ведения бизнеса, а не на обеспечении правильного выполнения кода.
Во-вторых, с точки зрения качества, мы не можем полностью смоделировать из-за ограниченных ресурсов тестирования.У нас есть независимый компьютерный зал для тестирования, и в условиях ограниченного тестирования, как в полной мере использовать ресурсы и как смоделировать больше сценариев - это все качества, которые мы должен столкнуться с вопросом.
Во многих бизнес-ориентированных компаниях тестирование кажется обязательным, что мешает компании быстро начать работу. Как обеспечить более быструю обратную связь, чтобы студенты QA могли вмешиваться раньше, проверять раньше, проводить тестирование в реальном времени и быстрее подключаться к сети, также является огромной проблемой. Кроме того, как понять общее качество и контроль качества всего процесса создания кода — это проблемы, требующие инженерного внимания.
В-третьих, с точки зрения эксплуатации и сопровождения порядки сервисов, которыми необходимо управлять и поддерживать для эксплуатации и сопровождения после разделения сервисов, увеличиваются в несколько раз или десятки раз, а сложность архитектуры эксплуатации и сопровождения возрастает. может быть развернут независимо, из-за внутренних зависимостей, независимо развернутый микросервис непредсказуем, или функция не может быть полностью реализована. Хотя мы демонтировали развертывание для повышения скорости, но после демонтажа, как обеспечить отсутствие проблем при закрытии. Столкнувшись с такой сложной архитектурой, как улучшить эффект эксплуатации и обслуживания?
решение
Решение описано ниже. Стандартизация, я опущу содержание о том, как заставить команду быстрее выполнять итерации по проекту, а затем сразу расскажу о гибкой разработке, как сделать контроль качества всего процесса. Основное внимание будет уделено тому, как разместить процесс НИОКР на платформе, чтобы процесс разработки больше не был ведомственным барьером, а действительно каждый мог видеть свой собственный процесс взаимодействия и расширенные услуги в процессе потока ценности. Я тоже опущу эту часть разведывательной информации, мы предприняли некоторые попытки, и они весьма эффективны, некоторые цифры будут для всеобщего обозрения позже.
стандартизация
Во-первых, вводится процесс производства кода. Мы используем github для управления кодом и построили относительно полную систему непрерывной интеграции. Инженеры могут отправлять несколько и частые отправки, чтобы быстро получать отзывы о качестве для каждого фрагмента кода. Здесь отзывы будут включать модульное тестирование, соответствие требованиям по покрытию и проверке кода. . Кроме того, я рекомендую, чтобы процесс КИ занимал не более 10 минут, если он не может достичь такого уровня, необходимо проанализировать, есть ли проблема с написанием УТ, что вызывает ваши потери, и есть ли узкое место в эффективности самой строительной платформы. Здесь проходит PR Auto Check, а код-ревью обычно делают один-два человека. Здесь я настоятельно рекомендую всем обратить внимание на просмотр кода, который является очень хорошим способом и возможностью для инженеров улучшить себя и стремиться к лучшему. После прохождения проверки кода он объединяется с веткой «Разработка», что автоматически запускает платформу для непрерывной доставки. Для продуктов с высокой степенью зрелости, если этот тест пройден, настроенный нами процесс ловушки автоматически перейдет в состояние, подлежащее выпуску.Как правило, продукты с уровнем зрелости будут иметь QA для бизнес-проверки и тестовые примеры, чтобы дополнить изменение состояния, которое вручную запускает jira, описанный здесь, — это полный процесс доставки функции. Координация этого процесса почти синхронна. Какие тесты могут быть разработаны и доставлены на уровне детализации проблемы, можно протестировать. Последующие платформы надеются поддерживать непрерывную доставку до тех пор, пока pr не сможет напрямую инициировать непрерывную доставку, что еще больше расширит возможности автоматической проверки и еще больше сократит расстояние между кодом и кораблем.
Это этап от предварительного релиза до релиза, и предыдущий функциональный код был протестирован. Когда Develop объединяется с master, он может инициировать непрерывную доставку и проверку, ориентированную на выпуск, а также выпуск по запросу с помощью платформы выпуска.
Как мы сотрудничаем?
Он использует конвейеры на основе ролей, ориентированные на роли и условия срабатывания, и мы определим конвейеры для самотестирования, интеграции и выпуска, чтобы установить механизм доставки. Настоящая маневренность в том, что ему больше не нужно тестировать в четверг или пятницу по условиям доступа, а мы можем тестировать в любое время, каждый день, и мы можем добавлять тест-кейсы в любое время в рамках автоматизированной проверки.
Процесс включает в себя обеспечение качества.Наша идея состоит в том, чтобы установить контрольные точки качества для различных триггерных условий и целей доставки, а также создать автоматизированную систему проверки для сбора данных о качестве для анализа.
Платформа
Платформизация находится в центре внимания сегодняшнего введения. Мы работаем над этой платформой больше года, и в процессе мы прошли через множество процессов, от незрелой контейнеризации до контейнеризованного состояния до состояния, которое можно контейнеризовать в масштабе.
Это описание возможностей универсальной платформы доставки исследований и разработок, которая поддерживает управление тестовой средой смешанного режима. Многие люди используют микросервисы, но на самом деле не все наши микросервисы реализованы один за другим, они могут быть реализованы один за другим Основная идея состоит в том, чтобы начать с stateless, а затем к stateful и базовым приложениям. Таким образом, мы также подумали о многих способах обеспечения стабильного качества и бесперебойной контейнеризации. Мы считаем, что мы должны поддерживать смешанный режим, и теперь мы поддерживаем две полные среды, содержимое которых контейнеризовано, мы управляем в контейнерах, которые не контейнеризованы, мы управляем в режиме совместимости, чтобы обеспечить непрерывность среды. Обновленная, поддержка всей системы исследований и разработок также постоянно обновляется. Кроме того, мы обеспечиваем оркестровку на уровне продуктов и услуг, легко управляем взаимосвязями и зависимостями микросервисов, собираем микросервисы в полные продукты и создаем конвейеры непрерывной доставки, ориентированные на роли. Мы выступаем за интеграцию разработки, тестирования, эксплуатации и обслуживания, поэтому мы будем управлять отношениями рендеринга и задействованными шаблонами унифицированным образом.
Цепочка инструментов доставки. В настоящее время некоторые из наших продуктов переведены на платформу непрерывной доставки версии 2.0 для доставки в контейнерах. Это связано с стадией продукта, бизнес-формой и сложностью. Мы будем постепенно мигрировать и поддерживать ее посредством оценки. В качестве тестовой среды я рекомендую всем использовать ginkgo.При работе с распределенными и одновременными тестами эффективность выполнения очень высока, а обслуживание очень легкое.Сама структура написана на ходу. На самом деле, нетрудно заметить, что мы не используем много инструментов.Я думаю, что инструменты зависят от того, умеете ли вы их использовать хорошо, и связать их с низкой умственной нагрузкой, чтобы вы могли действительно разобраться в процессе и легко включить его в платформу.
Расширенный сервис. Мы будем делать много услуг, встроенных в рабочий процесс, например, в процессе непрерывной интеграции мы собираем данные о качестве модульного тестирования и проверки кода как услугу. На этапе непрерывной доставки поддерживаются службы интеграционного тестирования и покрытия. Мы расширили наши услуги по тестированию на различные сценарии среды, такие как интерактивные частные облака и облачное хранилище, и мы также можем запускать направленные прогоны, чтобы проверить успешность развертывания в оттенках серого. Кроме того, мы также попробовали Chaos engineering и возьмем множество деструктивных программ, чтобы убедиться, что служба надежна. Затем эти сервисные возможности будут постепенно включены в новую систему непрерывной доставки.
Введение в микросервисную архитектуру
Во-первых, давайте поговорим об инженерных концепциях. Всем всегда было интересно, что же такое микросервисная архитектура? Каково мировоззрение микросервисов? Вот мое личное мнение: когда мы сталкиваемся с большим количеством сценариев и предприятий, нам приходится иметь дело с возросшей сложностью размера нашей команды, требованиями высокой доступности системы и высокой параллелизма, а также с тем, как позволить большему количеству людей развиваться более эффективно и в общий объем бизнес-процедур? Мы обнаружили, что микросервисы могут позволить большему количеству людей участвовать в разработке и доставке сложных систем.Мы разделили наиболее подходящие микросервисы в соответствии с бизнес-архитектурой, чтобы добиться эффективного сотрудничества с помощью соглашений об интерфейсе.
Микросервисы — это процесс превращения частей в целое и упрощения сложностей.Платформы непрерывной доставки обеспечивают возможность сборки и управления. Платформа автоматизации должна быть стабильной, а случай автоматизации должен быть в состоянии покрыть возможности доставки, чтобы он действительно мог обеспечить непрерывный выпуск самообслуживания и непрерывное развертывание в определенной степени.
Общая архитектура Spock несложна и поддерживается бизнесом, сервисом и базовыми сервисами. Для базовой Услуги мы используем собственное хранилище Qiniu Cloud, большие данные и контейнерное облако для решения различных проблем. Например, для хранения мы будем размещать доставленные пакеты и журналы в облачном хранилище для резервного копирования и использовать продукты для работы с большими данными, чтобы обеспечить возможности анализа и мониторинга журналов в реальном времени. Контейнер является основным нижним уровнем.Наша команда контейнеров предоставляет очень стабильный и надежный контейнерный кластер и различные базовые приложения-компоненты.
На приведенном выше рисунке показано представление результатов рабочего процесса платформы. Справа есть связанный вопрос, а соответствующая кодовая база и сервисный контент будут ниже, что является базовой информацией и конструкцией. После развертывания конструкции в развертывании будет информация о продукте и среде развертывания, а также о том, какое тестирование оно прошло.Будет отражена вся информация и интерактивное управление, связанное с управлением проектами, управлением кодом, управлением средой и серийным выпуском. здесь.
Это наша система качества и эффективности, которая анализирует некоторые показатели качества и эффективности в процессе непрерывной доставки, чтобы помочь нам выявить недостатки качества и эффективности. Показатели здесь являются их частью.Эти показатели будут выбираться из множества количественных показателей каждый квартал и полгода, чтобы улучшаться и размещаться здесь.Оценка и вознаграждение внутренних отличных команд также будут относиться к данным и вознаграждениям качества и эффективности. Это также будет включать различные роли в цепочке доставки, а не физический отдел.
Я также поделюсь с вами здесь своими взглядами.Все показатели не должны быть абсолютной ценностью оценки людей, потому что грамотность людей многомерна и не может быть полностью оценена в цифровом виде, но эти данные могут отражать определенную доставку и командную работу.Возможности совместной работы, такие как частота доработок, в определенной степени отражают переработку и качество; модульное тестирование и соответствие на самом деле являются оценкой качества кодовой базы; реагирование на инциденты является результатом последних усилий всей команды, направленных на то, чтобы сделать сервисы высокодоступными.
Уровень, которого мы достигли сейчас, заключается в том, что основной модуль составляет более 60%, соответствие кода основного модуля составляет более 80 баллов, скорость непрерывной доставки составляет более 85%, степень покрытия E2E+API централизованным тестированием составляет более 35%, и уровень серьезности аварии снизился на 10% % или более, эффективность сборки составляет 2-10 минут, а скорость устранения дефектов составляет 82,97%. Часть QA перешла от разработки тестов к состоянию инструментов разработки или услуг тестирования.
Выше представлена картина практических результатов нашей платформы: доля растущего бизнеса снижается, а уровень качества неуклонно повышается. Платформа качества была запущена в начале 2016 года, и некоторые показатели были сокращены по необоснованным причинам.В конце концов, было больше показателей 20 до примерно показателей 10. Окончательно извлеченные основные показатели в основном связаны с положительным продвижением проекта .
Спасибо вам всем.