Наш подход в целом схож — максимально упростить работу команд разработки. Да, мы планируем реализовать набор преднастроенных типовых конфигураций. Тем не менее сам pipeline будет полностью прозрачен — пользователь будет видеть, какими инструментами пользуется — даже будет иметь возможность изменять настройки и заменять сами инструменты.
1. Мы хотим сделать не просто набор инструментов из которых можно собрать pipeline, а интегрировать их, связать предварительными настройками и сделать единый фронт.
Особое внимание мы хотим уделить фичам по мониторингу реализации задач исполнителями — быстрый срез основных метрик, начало этапов сборки/тестирование/деплоя, процент выполнения ревью кода, процент документирования, соответствия стандартам кода и т.д.
А также удобным механизмам для сбора KPI и отображение в виде наглядных дашбородов, которые позволят бизнесу видеть оперативные показатели качества работы команд — скорость, качество кода, делать бенчмаркинг по показателям между командами, проверять результативность изменений в работе команд (как меняются показатели по результатам изменений. Примеры изменений — длина спринта, методы тестирования), а также выявлять тенденции деградации показателей для принятия мер по диагностике и устранению причин.
2. Мы не утверждаем, что у нас больше компетенций, например по Kubernetes, чем у специалистов Google. Мы опираемся на опыт нашей внутренней разработки, а также на ряд уже реализованных on-premise проектов (достаточно кастомизированных) для наших заказчиков.
Даже и сайтик про котиков с низкой посещаемостью, который крутится на 1-2 виртуалках, в 2к18 скорее всего:
делается на каком-нибудь web-фреймворке или генераторе статических сайтов;
хранит исходники в системе контроля версий;
кодится и тестируется хипстером (вариант — хардкор-девелопером-отцом) на своем макбуке с макосью (вариант — леново со слакой) с докер-контейнерами для тестовой базы и тестовым redis, потому что их проще всего поднять и погасить.
Из этого состояния, как мне кажется, идея настроить авто-деплой в кубернетис-кластер посредством конфиг-файла, который помещается вместе с исходниками, выглядит достаточно привлекательно и почти совсем не оверхед.
Какие есть альтернативы для сайта с котиком? Делать руками git pull на виртуалке с сайтиком при изменениях сорца и настроить там хуки, чтобы переподнимать сервис при обновлении? Сделать ansible-плейбук и запускать его вручную? Написать скрипт для тревиса, который подключится к github-у (вариант — описать bitbucket-pipeline), который scp-скопирует файлы в целевую виртуалку и перезапустит service по ssh?
К альтернативным способам тоже есть вопросы. Как бы это делали вы?
В этом мире вы всё равно будете доверять провайдерам сети, облачному провайдеру (например, нам), производителям железа, разработчикам софта. Есть несколько способов правильно параноить, но они подразумевают собственное производство процессоров в конечном итоге. Что и делают военные в ряде ситуаций.
Мы понимаем, что для больших команд и проектов необходимо наличие нескольких сред для деплоя и данную возможность планируем к реализации. Подскажите, какое количество сред вы обычно задействуете для своих проектов?
Спасибо за вопрос. Да, мы планируем реализовать для разработчиков возможность разворачивать собственные песочницы, чтобы можно было самостоятельно деплоить в stage.
1. Мы хотим сделать не просто набор инструментов из которых можно собрать pipeline, а интегрировать их, связать предварительными настройками и сделать единый фронт.
Особое внимание мы хотим уделить фичам по мониторингу реализации задач исполнителями — быстрый срез основных метрик, начало этапов сборки/тестирование/деплоя, процент выполнения ревью кода, процент документирования, соответствия стандартам кода и т.д.
А также удобным механизмам для сбора KPI и отображение в виде наглядных дашбородов, которые позволят бизнесу видеть оперативные показатели качества работы команд — скорость, качество кода, делать бенчмаркинг по показателям между командами, проверять результативность изменений в работе команд (как меняются показатели по результатам изменений. Примеры изменений — длина спринта, методы тестирования), а также выявлять тенденции деградации показателей для принятия мер по диагностике и устранению причин.
2. Мы не утверждаем, что у нас больше компетенций, например по Kubernetes, чем у специалистов Google. Мы опираемся на опыт нашей внутренней разработки, а также на ряд уже реализованных on-premise проектов (достаточно кастомизированных) для наших заказчиков.
Из этого состояния, как мне кажется, идея настроить авто-деплой в кубернетис-кластер посредством конфиг-файла, который помещается вместе с исходниками, выглядит достаточно привлекательно и почти совсем не оверхед.
Какие есть альтернативы для сайта с котиком? Делать руками git pull на виртуалке с сайтиком при изменениях сорца и настроить там хуки, чтобы переподнимать сервис при обновлении? Сделать ansible-плейбук и запускать его вручную? Написать скрипт для тревиса, который подключится к github-у (вариант — описать bitbucket-pipeline), который scp-скопирует файлы в целевую виртуалку и перезапустит service по ssh?
К альтернативным способам тоже есть вопросы. Как бы это делали вы?