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