Взгляд через призму CMMI

Проблема разработки вне виртуальных окружений стара как мир, но новички входят в профессию постоянно. Каждый проходит один и тот же путь и спотыкается об одни и те же вопросы. Как сделать процесс разработки по-настоящему зрелым?

Недавно я переосмысливал свой опыт и в "чертогах своего разума" наткнулся на идею построения процессов через модели зрелости. Хочу поделиться наблюдением: почему использование классических python -m venv и uv venv — это менее зрелый подход, чем связка Conda (Mamba) + Docker.

Для начала освежим в памяти уровни зрелости по CMMI: — Начальный (Initial): Хаос. Успех зависит от героев-одиночек, а не от системы. — Повторяемый (Repeatable): Есть базовые практики управления. Прошлые успехи можно осознанно повторить. — Определённый (Defined): Процессы стандартизированы и задокументированы для всей команды. — Управляемый (Managed): Качество и процессы измеряются количественно, контролируются метриками. — Оптимизируемый (Optimizing): Фокус на постоянном улучшении на основе данных и инноваций.

Потолок обычных окружений

Использование python -m venv или uv venv в лучшем случае дотягивает до второго уровня зрелости. Да и то, только если вы дисциплинированно фиксируете pip freeze > requirements.txt или используете uv add -r requirements.txt.

Да, это самый простой порог входа. Без виртуального окружения сейчас уже никуда: и ОС, и IDE блокируют установку пакетов в систему. Делать это в системный Python сегодня — всё равно что пушить напрямую в мастер, игнорируя всю команду.

Почему Conda + Docker — это шаг вперёд

Я считаю, что эта связка поднимает планку минимум до третьего уровня зрелости. Вот главный аргумент: разработка ведётся в контейнере. После пуша в Git-репозиторий окружение можно идентично воспроизвести на любой машине, независимо от ОС. Более того, этот же образ контейнера можно запускать в продакшене — а это уже попахивает пятым уровнем (воспроизводимость от дева до проды).

Отдельный плюс — бесшовная работа с VSCode. Расширение Dev Containers позволяет подключаться к уже запущенному контейнеру (Attach to Running Container). И вот здесь внимание: вы можете продолжать разработку, не перезапуская контейнер при каждом изменении кода! Это не «песочница», из которой надо выходить, чтобы что-то поменять. Обновить зависимости или служебные пакеты можно тихо и незаметно из соседнего окна терминала командой docker compose run --rm ....

А зачем тогда Conda или Mamba?

Они остаются как «родное», легковесное окружение для локального запуска служебных операций, не влияющих на продакшен-среду. Например, для запуска e2e-тестов, которые по сути выступают внешним сервисом. Но можно пойти ещё дальше: собрать отдельный контейнер только с тестами. В этом случае оверлей в виде Conda на хостовой машине вообще не понадобится.

Итоговая оценка

Несмотря на то что контейнеры прозрачно проходят путь от дева до проды, использовать эту связку локально как полноценный «пятый уровень» я бы не стал. Всё же Conda/Mamba применяется для локальных экспериментов, подключения AI-инфраструктуры и черновой работы. Поэтому мой вердикт: это стабильный третий уровень (Defined) с огромным потенциалом для масштабирования на четвёртый и пятый.

А как вы оцениваете зрелость вашего стека? Давайте обсудим в комментариях.