Старт любого нашего проекта начинается с подготовки инфраструктуры. Времени на это порой уходит довольно много. Как минимум необходимо нарезать виртуалки или донастроить Kubernetes, настроить CI, базы данных, логирование, мониторинг и прочие компоненты. В лучшем случае в этих заботах проходит несколько дней, а ни строчки кода еще не написано. Знакомая ситуация? Лучшим решением для нас стал собственный набор сервисов, инструментов и подходов — CUSTIS Labs. Он помог нам сократить время подготовки инфраструктуры с нескольких дней до минут. Также убрал лишние коммуникации, которые возникают между разными специалистами при создании инфраструктуры вручную. Теперь разработчику не надо узнавать у девопса, где лежат логи, где находятся метрики сервиса и как подключиться к базе — все настраивается и сообщается разработчику автоматически. Настройка быстрого старта не единственная задача, которую решает CUSTIS Labs. Подробнее о других его функциях расскажем в следующих статьях. Популярный на рынке способ быстрого старта — все всегда стартовать в Kubernetes — мы отмели сразу.  Во-первых, сам Kubernetes не всегда подходит под конкретные задачи. Для определенных работ сейчас есть более удобные и эффективные инструменты. Например, с базами данных пока лучше работать вне Kubernetes.  Во-вторых, стенд разработки и тестирования на нашей стороне должен быть максимально похож на стенд клиента. А на всех проектах заказчик разный, со своими особенностями и стандартами. В отделе разработки у нас есть группа MVP (minimum viable product), она же группа прототипирования. Это небольшая команда, состоящая из одного-двух фулстек-разработчиков и тимлида. Основные задачи этой команды — тестирование гипотез, разработка коммерческих предложений и запуск новых проектов. Для решения этих задач как раз очень хорошо подходит Kubernetes. В отделе прототипирования все происходит стремительно. От задумки до прототипа должны проходить максимум дни. Идея, сбор команды, прототип, демо — и так постоянно.  Ребята как можно быстрее должны приступить к написанию бизнес-логики, не отвлекаясь на выделение инфраструктуры под проект, создание баз данных и прочее. Мы используем популярные на рынке технологии. Техстек и инфраструктура проектов в отделе MVP выглядит так: Kubernetes как среда исполнения контейнеров; PostgreSQL как СУБД; В GitLab мы храним код; GitLab CI — наша сборка и деплой; OpenSearch, Grafana, Prometheus — сбор и визуализация метрик и логов; Выбор языка программирования зависит от клиента, но, как правило, это Java/.NET; Кэш — Redis; Очереди — RabbitMQ. Как видите, все довольно стандартно. Итак, для старта проекта команде MVP необходимо: Подготовить инфраструктуру; Создать проект в GitLab; Создать для проекта базу данных; Настроить CI; Настроить логирование и сбор метрик; Настроить внешний URL проекта для заказчика; Выписать для этого URL необходимые сертификаты. Для того, чтобы все это автоматизировать, нужен был какой-то подход. Мы посмотрели вокруг и поняли, что модель ChatOps наиболее подходящая в нашем случае.  Создали бота в Телеграме и подключили его к нашему CI. Бот принимает определенные команды, в недрах инфраструктуры происходит запуск pipelines и по результатам внутренней магии бот рапортует пользователю о проделанной работе. Пример: Командуем боту /newproject, отвечаем на вопросы по названию проекта, типу бэкенда, наличию фронтендa, необходимости в базе данных. Через некоторое время получаем в ответ URL созданного проекта или группы проектов в GitLab с кодом и уже настроенным CI, описанной инфраструктурой в Terraform, а также URL для доступа к логам, метрикам и URL для клиента. Всё, что нам надо для работы, готово. Предлагаем посмотреть, как это устроено. Общая схема работы: Бот получает данные от пользователя и: Дергает API GitLab для запуска pipeline проекта INFRA Runner подхватывает pipeline и: создает репозиторий из заранее подготовленного шаблона; создает БД для проекта, если необходимо; в последнем шаге pipeline и сообщает в чат о проделанной работе. Основная логика работы находится в проекте INFRA. Выглядит он как стандартный репозиторий с Ansible: … files inventory roles templates deploy-new-db.yml deploy-new-gitlabproject.yml .gitlab-ci.yml …. Для проекта INFRA мы создали pipeline trigger и добавили вызов этого триггера в логику работы бота, тут всё по документации: Бот вызывает этот POST с нужными нам параметрами. Далее Runner подхватывает pipeline и выполняет по очереди шаги из секции scripts: Создает новый проект из templates в GitLab. Создает новую БД для проекта, если необходимо. В самом конце рапортует пользователю о проделанной работе: Структура созданного проекта кроме кода каркаса сервиса на указанном языке программирования содержит типичный набор компонент для деплоя.  На примере бэкенд-сервиса: Код каркаса сервиса на C# или Java; Dockerfile; .helm файлы; .gitlab-ci.yml с шагами сборки, проверки на безопасность и деплоя. Пользователю после получения сообщения от бота осталось только сделать git clone и написать бизнес-логику :-)  Commit, Push и деплой на dev-стенд стартует автоматически. После тестов, сборки и деплоя наш проект доступен по адресу  https://dev-<projectname>.labs.domain.ru    Расскажите в комментариях, а как вы решаете задачу быстрого старта? Мы рассмотрели только один случай применения CUSTIS Labs. Однако у нас его активно использует не только группа MVP. В других отделах разработки, где продукты уже внедрены, важна стандартизация компонентов проекта — единые шаблоны, форматы и вводные. Когда первые шаги стандартны, гораздо легче работать: база сама создается, логи в одном месте, — бери и пиши код. Кроме того, упрощается вход новых сотрудников в проект, которые должны как можно скорее начать ориентироваться в нем и приступать к решению бизнес-задач. Тоже самое справедливо и при переходе с одного проекта на другой. Со всем этим нам также помогает CUSTIS Labs.  В следующий раз подробно расскажем про то, как мы стандартизируем и управляем компонентами на проектах на примере СУБД PostgreSQL.