В дополнение к одному из моих предыдущих постов.
Еще раз начал обсуждать практики DevOps / Lean Software Development с командой, ответственной за практики разработки. На текущий момент только один человек потратил время и почитал про основные практики вышеперечисленных подходов. После этого он восторженно рассказал мне, как все это может круто работать и ужаснулся, так как внедрять все эти подходы будет непросто. Это при том, что все члены команды сделали self-assessment их собственных команд, согласно практикам из предложенных подходов, и только один прочитал что же они означают!
Контекст
Одна из проблем текущих практик жизненного цикла проектов запуска платформы для интернет магазина, это то, то накапливаются большие куски функциональности, которые тестируются неделями и клиент получает продукт поздно и за очень дорого.
В идеале нужно проверить все этапы жизненного цикла продукта (релиза) и соответствующие практики на предмет того, где затор. Для проверки гипотез, можно использовать практику Value Stream Mapping. DevOps process: Visibility of work in the value stream | Google Cloud .
Основные практики
В практиках управления жизненного цикла можно выделить практики инженерии и рассмотреть самые современные подходы. Один из подходов это Devops, как я писал ранее. В него входят несколько инженерных практик. Самые важные практики:
- Develop in small batches. One of the most important enablers of trunk-based development is teams learning how to develop in small batches . This requires training and organizational support for the development team.
- Perform synchronous code review. As discussed previously, moving to synchronous code review, or at least ensuring that developers prioritize code review, helps to ensure that changes don’t have to wait hours, or even days, to get merged into trunk.
- Implement comprehensive automated testing. Make sure that you have a comprehensive and meaningful suite of automated unit tests . and that these are run before every commit. For example, if you’re using GitHub, you can protect branches to only allow pull request merges when all tests have passed. The Running builds with GitHub Checks tutorial shows how to integrate GitHub Checks with Cloud Build .
- Have a fast build. The build and test process should execute in a few minutes . If this seems hard to achieve, it probably indicates opportunities for improvement in the architecture of the system.
Системные уровни
Проблемы с описанием этих практик, в том, что они описаны не системно, и связаны друг с другом, из за этого непонятно, с какой стороны подходить к их обсуждению, я уж не говорю о внедрении.
На мой взгляд, можно выделить следующие системные уровни систем создания, которые мы будем изменять:
- Инженерные практики на уровне индивидуальных ролей в команде, например практики Devops engineers, Tester и прочее. Можно назвать это культурой члена команды.
- Инженерные практики на уровне команды можно назвать это культурой команды
- Инженерные практики на уровне всех команд какой то платформы/технологии в рамках компании - культура сообщества/коммьюнити
- Инженерные практики на уровне компании
На уровне ролей в команде можно выделить 4 основные роли, ответственные за инженерию: Engineer/Devops Engineer, Requirements Engineer, Solution Architect, Tester.
Тогда например, практики, для Devops Engineer будут выглядеть как:
Роль: DevOps инженер
Дисциплина: Software Engineering, DevOps Engineering
Практики: Планирование Работ, Создание архитектуры, Управление конфигурацией, Создание кода, Проверка Кода, Деплой Кода, Откат кода.
Подпрактики планирования работ: Small Batches Of Work / Architecture that will support the small batches of work
Подпрактики создания архитектуры: Тут практически ничего у Devops нет, кроме общих рекомендаций
Подпрактики создания кода: test driven development, сommitting code every day, Проверка выполнения всех автотестов, приоритизация проблем с билдом приложения, code maintability / reusability, feature flags
Подпрактики управления конфигурацией: trunk-based development, храниние конфигураций приложения в системе управления конфигурацией, управление изменениями в базе данных
Подпрактики проверки кода: Synchronous code review, continuous testing
Подпрактики деплоя кода: zero downtime deployment, blue-green deployment или canary deployment
Подпрактики отката кода: тут особо нет информации и эти практики входят в Continues Deployment
На уровне команды, DevOps предписывает след практики:
Independent Tools Selection, Independent Deployment, Architecture (если Decoupled Architecture или Micro Services тут за каждый кусочек может быть ответственна своя команда), Team Experimentation, Collecting Feedback from customers, Work in Small Batches (та же практика что и для роли, но только для команды в целом), Streamlined Change approval
На уровне технологии / платформы мы будем рассматривать только те практики, которые имеют смысл. Например, SaaS платформы электронной коммерции не дают доступа к базам данных, и например такая практика как Database Change Management не будет применима к проектам на этой платформе.
Тогда, можно сказать, что на уровне компании мы рассматриваем DevOps практику инженерии или DevOps подход.
Сюда входят свои практики, например: job satisfaction measurement, learning culture, Westrum Organisation Culture.
В Learning Culture будут входить след подпрактики: bronwbags встречи, ideas sharing, training / certification of people
NB: почитать про практики инженерии тут: Software Delivery Guide