Хабрахабр

Мы хотим заменить девопсов скриптом (на самом деле нет): разработчики, нужно ваше мнение


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

Мы видим чёткий тренд, что сейчас скорость развёртывания новых проектов влияет на рынок. Основная идея — вы можете разворачивать конвейер с уже преднастроенными инструментами, но при этом с возможностью внесения целого ряда настроек, и вам останется только деплоить код.
Откуда такое извращение? От того, как быстро будут исправляться баги, как быстро будут заниматься новые ниши. От того, как быстро будут поставляться релизы, зависит коммерция. В первую десятку вошли технологии создания и управления контейнерами, а также бессерверная архитектура приложений и микросервисы, обогнав даже такую хайповую тему, как блокчейн. В начале 2018 глобальная компания «451 Research» провела опрос, какие технологии будут приоритетным при развитии.

И вот теперь у нас есть к вам пара вопросов.

Диаграмма из опроса:

А нужно ли это?

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

У использования контейнеров есть ряд преимуществ:

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

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

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

При чём тут облако для разработки?

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

Когда нужно что-то собрать — GitLab Runner. У нас было так: есть Гитлабчик с задачами и исходником. Когда ветка попадает в хранилище, в GitLab’е запускаются тесты по этому коду. Работаем по Git Flow, все фичи по отдельным веткам. После ревью ветка принимается, вливается в dev-ветку, по ней еще раз проходят тесты. Если тесты прошли, разработчик этой ветки может сделать мердж реквест, фактически запрос на ревью кода. И вот тут первый затык — код мы просматриваем руками на предмет соответствия функционалу и это первое, что мы исправляем. При деплое GitLab Runner собирает Docker-контейнер и выкатывает на стеджинговый сервер, где его можно будет покликать и порадоваться. И для неё у нас раскатывается отдельный пред-продуктивный вариант нашего решения, который смотрят наши бизнес-заказчики. После этого мы вливаем код в ветку релиза. Есть автогенерация release notes и отчёты по багам. После того как заапрувлена версия на пре-проде, мы ее катим в продакшн и она раскатывается на продуктовые ноды. Мы подобрали набор инструментов для себя и теперь думаем о том, как сделать такой же готовый SaaS. Скорость сборки была больше 30 минут, сейчас на порядок меньше.

Непосредственно типовой процесс вывода релиза для нас выглядит следующим образом:

  1. Постановка задач на реализацию новых фич
  2. Локализация кода
  3. Внесение изменений согласно поставленным задачам. Написание автоматических тестов перед билдом.
  4. Проверка кода, как ручная, так и автотестами
  5. Сливание кода в dev-ветку
  6. Сборка dev-ветки
  7. Разворачивание тестовой инфраструктуры
  8. Деплой релиза на тестовой инфраструктуре
  9. Запуск тестирования, функционального, интеграционного и т.д.
  10. В случае возникновения багов, допиливание их сразу в dev-ветке
  11. Перенос dev-ветки в master-ветку

Вот схема с деталями для нашего процесса:


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

Что за продукт мы планируем?

Мы решили не копировать Amazon в этом плане, а вести свою разработку с учётом специфики рынка. Сразу оговоримся, что все выкладки — наше субъективное мнение, основанное на нашем анализе. Мы открыты к конструктивному диалогу и готовы менять roadmap продукта.

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

Но в силу того, что проекты, как правило, довольно разветвленные, со сторонними микросервисами, — в какой-то момент становится нужно выкатывать кастомные docker-образы с DBaaS’шными сервисами и все это в Herocku не особо помещается, потому что либо дорого, либо неудобно. С другой стороны есть, например, Heroku, где можно деплоить в один клик.

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

Так что это будет?

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

  • Среда разработки (система управления конфигурациям, система постановки задач, репозиторий для хранения кода и артефактов, таск-трекер)
  • CI – Continuous Integration (сборка, инфраструктура и оркестрация)
  • QA – Quality Assurance (тестирование, мониторинг и логирование)
  • Staging – Среда интеграции / Предрелизный контур
  • Production – Продуктивный контур

Выбирая инструменты, мы ориентировались на best-practice на рынке.

Мы будем выстраивать инфраструктуру с Stage’ом и Prod’ом, с использованием Docker и Kubernetes с параллельным запиливанием фич.

Это будет происходить итерационно — на первом этапе запланирован сервис, который позволит брать Docker-файл из проекта, после чего собрать требуемый контейнер и раскладывает их Kubernetes.

Что мы понимаем под этим сервисом? Также мы планируем уделять особое внимание сервису по контролю процесса разработки и непрерывной поставки. Это возможность сформировать иерархическую модель KPI с показателями типа % покрытия юнит-тестами, среднее время устранения инцидента или дефекта, среднее время от коммита до поставки и т.д.

Сбором исходных данных из разных систем — систем управления тестированием, управления задачами, компонентов CI/CD, средств мониторинга инфры и т.д

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

Что мы хотим сделать

Собственно, от вас мне бы очень хотелось услышать мнение по поводу всего вот этого и наших планов по шагам. Сейчас они такие:

  • Инфраструктура и оркестрация — Docker & Kubernetes
  • Постановка задач, хранение кода и артефактов, task-tracker — Gitlab, Redmine, S3
  • Производство и разработка — Chef / Ansible
  • Сборка — Jenkins
  • Тестирование — Selenium, LoadRunner
  • Мониторинг и логирование — Prometheus & ELK
  • Кстати, а как вы смотрите на то, если в рамках платформы будет возможность выбора — захотел, выбрал Jenkins, не захотел — GitLab Runner?
  • Или же не важно, что внутри, главное, чтобы всё как надо билдилось, тестилось и деплоилось?

Как можно помочь?

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

Прямо сейчас расскажите, пожалуйста, какие стеки вы используете. Можно — в комментах или письмом на почту team@ts-cloud.ru.
UPD: для удобства мы сделали короткий опросник в Гугл-форме — вот тут.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть