- Убедитесь, что ваша среда разработки является снимком вашей рабочей среды.
- Убедитесь, что ваша система сборки / развертывания работает в Dev так же, как и в Prod.
- Убедитесь, что каждое развертывание изолировано от всех других развернутых приложений / служб.
- Убедитесь, что среды разработки и тестирования имеют легкий доступ к данным продукта.
Либо только для чтения, либо с копией.
В одной компании, в которой я работал, все коробки Dev / Test / Prod имели один и тот же базовый образ.
Теперь мы, разработчики, склонны впадать в уныние и устанавливать наши собственные пользовательские инструменты и т. Д. (И я никогда не встречал разработчика, который не настраивал свою среду), но в этой компании все было в порядке: инструменты сборки будут создавать и развертывать код на вашем компьютере точно так же, как и код, развернутый в рабочей среде (так что любые установленные вами пользовательские инструменты не будут доступны (по умолчанию)).
Инструменты сборки автоматически обнаружили все зависимости и развернули их вместе с вашим приложением (в том же каталоге (или символьные ссылки в каталоге вашего приложения)) и соответствующим образом установили путь. Система сборки также может быть развернута на рабочем столе другого разработчика или протестирована или продвинута точно таким же образом, только с несколькими дополнительными параметрами.
Другая компания, в которой я работал, использовала виртуальные машины.
Я не нашел такую среду комфортной. Проблема заключалась в том, что хотя теоретически виртуальная машина была точной копией среды prod, которая только усложняла диагностику, когда что-то пошло не так.
- Проблема здесь заключалась в том, что, поскольку виртуальная машина была средой тестирования, компания считала, что устройства dev не должны соответствовать тем же спецификациям, что и машина prod, или требовать одну и ту же ОС (ошибка первая: как вы теперь можете надежно отлаживается в dev).
- Инструменты, которые мы устанавливаем на нашу машину, часто очень полезны, когда что-то идет не так. Мы устанавливаем их один раз, затем мы можем быстро их настроить и использовать, когда что-то пойдет не так. Если вы используете виртуальную машину (которая является копией prod), вам нужно оставить все дополнительные инструменты в качестве установщиков и начать установку всех этих дополнительных инструментов на виртуальной машине (это трудоемко и требует много времени).
- Примечание. Ваша система сборки должна быть в состоянии развернуть ваш код локально, чтобы ваши инструменты по умолчанию не влияли на него. Вы должны иметь возможность подключить их к работающей системе.
- Я всегда предполагал, что виртуальные машины - это просто образ, который можно запустить.
- Я не знаю, почему эта система сборки заняла так много времени, но потребовалось 45 минут, чтобы подготовить виртуальную машину и настроить соответствующую среду (Теперь я не знаю, почему я никогда не изучал ее (у нас была сборка и тестовая команда смотрела на это, так что я их тоже оставил)).
- Из-за постоянных исправлений безопасности образы виртуальных машин обычно отклонялись от рабочей машины (и были не такими точными).
- Находясь в компании A, все dev / test / prod получили одинаковые патчи в одно и то же время. Примечание. Исправления безопасности не были автоматическими. Все исправления должны были быть проверены производственной и сборочной командами, чтобы убедиться, что они не влияют отрицательно на производственные системы. Но как только это было установлено, патчи были применены ко всем системам автоматически.
- Хотя образы виртуальных машин в компании B не работают, исправления безопасности не применяются автоматически. Оказалось, что для создания совершенно нового виртуального образа требуются согласованные усилия (мне бы хотелось, чтобы это было автоматизировано (я полагаю, что это возможно?)), Поэтому даже когда исправления безопасности применяются к prod / dev, они не применяются автоматически к виртуальный образ. Таким образом, виртуальные образы были синхронизированы с производством только каждые шесть месяцев.