В большинстве настроек DevOps вы обнаружите, что в трубопроводе есть несколько сред. У вас могут быть условия, которые изменяют окружающую среду, основанную на том, какую ветвь была объединена или когда ветка помечена для выпуска. Есть несколько причин, по которым вы хотите иметь больше, чем просто производственная среда, самой большой причиной тестирования.
Имейте в виду, что каждая организация делает вещи немного по-другому. Вы можете увидеть больше средних средств, чем они, покрытые здесь, или они могут не иметь такого же имена. Важной частью состоит в том, чтобы знать, какую цель служит для каждой среды. У них будет разные уровни доступа к услугам и различной общественной стороне доступа.
Среды, которые вы можете увидеть
Разработка
Окружающая среда разработки похожа на шаг от вашей местной среды. Это где вы можете развернуть небольшие изменения, чтобы увидеть, работают ли они где-то кроме локально. Ваш код не должен отлично работать, чтобы развернуть в эту среду. Вам может потребоваться проверить, как новая конечная точка интегрируется с вашим приложением, и вам нужно пройти проблемы по CORS.
Вы можете работать над большой особенностью с другими разработчиками в этой среде, когда все тестирующие подходы к функции или ошибке. Это похоже на передовую песочницу, которая дает вам немного больше доступа к другим услугам, чем ваша местная среда может позволить.
Постановка
В большинстве случаев именно здесь ваш код идет до того, как он будет отправлен на производство. Вы должны были получить обзоры кода и попробовали некоторые индивидуальные тестирования, чтобы убедиться, что все функциональные возможности там, и не было никаких регрессий. Изменения, которые развернуты для постановки, должны работать с небольшим количеством вопросов.
Именно здесь ваши тесты интеграционных тестов и любые сторонние службы получают необходимые вами секреты. Некоторые компании будут созданы полностью отдельными службами для постановки, потому что это окружающая среда, ближайшая к производственной среде, которую мы можем получить.
После того, как у вас есть ваш код на постановке, вы можете убедиться, что все данные загружаются так, как вы ожидаете, и что вы получаете правильные ответы от услуг. Это хорошее место для проведения инженерных испытаний CHAOS, чтобы проверить, насколько крепкая ваша система с ресурсами, имеющими доступность. Доступные ресурсы, которые устойчивый сервер, как правило, ниже, чем то, что производство имеет так, чтобы они имели в виду для тестирования производительности.
QA.
Вы увидите среды QA (обеспечения качества) в разных формах. Они обычно устанавливаются для инженеров по тестированию программного обеспечения для систематически Hunt Bugs и проблем с приложением с точки зрения пользователя. Это то, где придумывают много краевых сценариев.
Много раз вы увидите несколько средов QA, и все они обслуживают разные цели. Можно специально установить для сценариев края кромка, другой может запустить автоматические тесты пользовательского интерфейса, а другой может иметь вновь выпущенные функции, которые экспериментируются с.
Эти среды принимают ряд разных имен, поэтому вы можете не увидеть трубопровод с определенными командами для развертывания в QA. Познакомьтесь со структурой этих условий рано, если они используются на любых проектах, на которых вы работаете.
Производство
Это последняя среда для вашего кода. После того, как вы добрались до этого сервера, все ваши изменения живы для клиентов, чтобы взаимодействовать. Там не так много тестирования, которые вы можете сделать здесь, не повлияя на пользовательский опыт, и в этот момент вы сделали все возможное, чтобы проверить, что ваш код силен.
Производство, скорее всего, будет наиболее ресурсоемким, потому что время безотказной работы и производительность являются типичными метриками для того, насколько хорошо работает приложение для пользователей. Есть очень мало случаев, которые вы должны когда-либо развернуть напрямую к производству. Один конкретный случай, когда вы можете получить исправление для серьезных ошибок, которые влияют на пользователей.
В противном случае всегда лучше отправить ваши изменения кода в другие условия, которые находятся на месте. Большинство трубопроводов CI/CD развертывают код в нескольких средах параллельно, чтобы никто не ожидал, что вся среда для развертывания, прежде чем они смогут начать тестирование.
Обрабатывать данные по средам
Сохранение паритета во всех средах важно для них, чтобы они оставали полезны. Основная область, в которой вам нужна согласованность, в том, что данные. Если вы можете получить данные из производства и запутать его, это будет лучшие данные для развития. Это именно то, что пользователи видят, но со всей чувствительной информацией изменилась или отфильтрована.
Это также помогает иметь данные, которые воссоздают краевые случаи, если это возможно. Если проблема появилась в среде QA, то стоят время сделать данные для этого вопроса легко доступной. Это гарантирует, что нет никаких регрессий, проходящих через определенные условия, а не другие.
Когда у вас есть план для того, чтобы справиться с вашими данными по этим средам, он облегчает разработку и тестирование, которое поможет ускорить процесс развертывания. Существует небольшое устроенное время в дальнейшем, потому что копирование и модификация производственных данных могут занять некоторое время. Если вы можете, попробуйте импортировать достаточно данных, чтобы приложение работало так, как будто вы ожидаете.
Поддержание каждой среды
Поскольку вы знаете, что есть для каждой среды, есть всего несколько вещей, которые вам нужно учитывать. В долгосрочном обслуживании этих сред убедитесь, что вы знаете, у кого есть доступ. Хотя вы можете использовать цензуренные данные, все еще могут быть процессы и код, к которому не каждый нужен доступ.
Другая вещь, которая приходит, так это о том, как распределение ресурсов обрабатывается на предварительно производственные условия. В маловероятно, что в средах развития и качества будут иметь одинаковое количество серверов ресурсов в качестве производства. Это представляет другой набор ограничений, с которыми вам не нужно иметь дело с производством.
Когда вы пытаетесь выяснить проблемы с производительностью или вы пытаетесь контролировать услуги, осознавать свою среду. Это может быть то, что вы пытаетесь отлавить вместо фактической проблемы. Держите кэш-четко, удалите любые неиспользуемые ведра, и посмотрите на что-нибудь еще, что может болотать ваш рабочий код вниз.
Развертывание в различных средах на фазе CD
Когда вы хотите развернуть все эти условия, это, вероятно, будет частью процесса непрерывного доставки. Также у вас будет представление о том, что это может выглядеть в вашем трубопроводе, вот пример.
import conducto as co
def cicd() -> co.Serial:
image = co.Image("node:current-alpine", copy_dir=".")
cra_node = co.Exec("npx create-react-app random-demo")
installation_node = co.Exec("cd random-demo; npm i; CI=true; npm test")
build_node = co.Exec("npm build")
staging_node = co.Exec("echo sent build artifact to staging on an AWS server")
qa_node = co.Exec("echo sent build artifact to QA on a Heroku server")
prod_node = co.Exec("echo sent build artifact to prod on a Netlify server")
start_node = co.Exec("npm start")
pipeline = co.Serial(image=image, same_container=co.SameContainer.NEW)
pipeline["Make CRA..."] = cra_node
pipeline["Install dependencies..."] = installation_node
pipeline["Build project..."] = build_node
pipeline["Deploy to envs..."] = co.Parallel()
pipeline["Deploy to envs..."]["Staging"] = staging_node
pipeline["Deploy to envs..."]["QA"] = qa_node
pipeline["Deploy to prod..."] = prod_node
pipeline["Start project..."] = start_node
return pipeline
if __name__ == "__main__":
co.main(default=cicd)
Другие мысли
Это может показаться как много, чтобы отслеживать, но, как только вы понимаете, что ожидается от каждой среды, это просто часть процесса. Пока полномочия и разрешения поддерживаются в курсе, а ожидания установлены, работа с несколькими средами поможет вам получить лучший код пользователям.
Вы сможете быстрее получить отзывы от разных людей, и вы сможете более последовательно отслеживать ошибки и дыры безопасности. Это делает все тестирование и интеграции идут более гладкими, когда это действительно время, чтобы пойти на производство.
Убедитесь, что вы следуете за мной на Twitter Потому что я публикую такие вещи, как это и другие темы, все время!
Если вам интересно, какой инструмент вы должны проверить сначала, попробуйте Дирижер Для вашего CI/CD-трубопровода. Довольно легко встать и бежать, и даже проще отладить, пока он работает.
Оригинал: «https://dev.to/flippedcoding/how-to-manage-multiple-environments-with-devops-542m»