Я работаю в небольшой команде программистов, поддерживающей большую организацию. В этом году наш менеджер решил, что мы будем использовать технологии Oracle Apex для обработки большинства данных нашей компании.

Это было бы хорошо, за исключением того, что у нас есть только один сервер Apex. Наш менеджер постановил, что все происходит в этом случае. Наша команда разрабатывает приложения, в то время как наш менеджер демонстрирует их, а наши внутренние клиенты используют их, что по понятным причинам уже вызывает проблемы!

Я могу только ожидать, что это ухудшится, поскольку мы все больше инвестируем в Apex, приложения становятся все более сложными, и число пользователей растет. Я слышал, что лучше всего иметь отдельные среды разработки, тестирования и производства, но почему это так?

Вопрос: почему у нас должны быть отдельные среды разработки, тестирования и производства?

Почему у нас должны быть отдельные среды разработки, тестирования и производства?

У вас есть несколько действий одновременно:

• разработка - где разработчики фиксируют код, делают ошибки, экспериментируют и т. д.
• тестирование - там, где тесты выполняются вручную или автоматически и из-за сложности могут потреблять много ресурсов.
• производство - где создается ценность для клиентов и / или бизнеса

Вы хотите, чтобы все это происходило в одной среде? Хотите ли вы, чтобы бизнес остановился, потому что новый тест подтолкнул ваши серверы к замене жестких дисков и потребляет каждое ядро ​​процессора? Хотите ли вы, чтобы ваши тесты прекратились, потому что разработчик сделал замысловатую вилочную бомбу из масштабного эксперимента? Вы хотите, чтобы код, который, по вашему мнению, работал, из-за бечевки и клейкой ленты разработчика в тестах для запуска в производство? Хотите ли вы, чтобы разработчики работали с потенциально конфиденциальными производственными данными (я знаю, что это не проблема для всех предприятий, но во многих из них)?

Что мешает этим проблемам случиться?

Отдельные среды.

Так что тебе нужно?

Вам нужны отдельные среды.

Говоря формально

Вам нужны отдельные среды по следующим причинам:

• снизить риски блокирования бизнеса и разработки программного обеспечения.
• снизить риски внедрения кода в производство, которое прошло тестирование, из-за специального оснащения разработчиков.
• снизить риски попадания производственных данных в чужие руки (очень важно, когда организации имеют дело с конфиденциальными данными, такими как идентификационные номера и финансовая информация и информация о состоянии здоровья) или смешивание с тестовыми данными или их уничтожение.

Для вашего контекста новая технологическая платформа

Может быть, это еще не действительно производство (поскольку это относительно новая платформа), но вы получите свои отдельные среды, когда бизнес начнет полагаться на них, и они либо достаточно мудры, чтобы предвидеть риск, либо осознают его, изучая трудные вопросы. путь.

Я слышал, что лучше всего иметь отдельные среды разработки, тестирования и производства, но почему это так?

Это не так ясно, в эти дни.

Во многих местах больше не проводят ручное тестирование, поэтому сами по себе не имеют тестовых данных. Многие другие места имеют такой масштаб, что они не могут воспроизвести свою производственную среду из-за стоимости. И особенно в связи со взрывным ростом количества микросервисов становится все труднее поддерживать достаточно быстро синхронизирующиеся среды, чтобы гарантировать, что тестирование в среде QA точно воспроизводит вещи, чтобы выявить ошибки, которые будут обнаружены в работе.

Почему у нас должны быть отдельные среды разработки, тестирования и производства?

• Если ваши тестовые данные будут видны пользователям, это будет очень плохо.
• Если бы ваши продуктовые данные были видны разработчикам / тестировщикам, это было бы очень плохо.
• Если вы не можете доверять своим разработчикам, чтобы они не ломали вещи, и вы не можете быстро исправить эту ситуацию.
• Если у вас есть автоматизированный CI, который продвигает код быстро и легко.

По сути, если стоимость наличия окружения меньше, чем стоимость отсутствия окружения .

Основная (и наиболее очевидная) причина заключается в том, что вы никогда не хотите смешивать данные тестирования и производства. Это может очень быстро запутать как пользователей системы, так и разработчиков. Когда вы проводите проверку качества и модульные тесты (что вам следует делать), вы должны убедиться, что они находятся в полностью изолированной среде. Если что-то взорвется в вашей среде разработки или в QA, это отрицательно скажется на производстве и, следовательно, на живых пользователях и их важных данных! Вы абсолютно не хотите, чтобы это производило эффект!

Это распространяется на обычные службы, которые вы должны использовать в своей повседневной работе, такие как контроль версий. Вы не можете правильно использовать контроль версий, если код, которым вы управляете, находится в живом окружении! Ваши пользователи будут сходить с ума - что если вам нужно отменить или откатить назад? Что делать, если вы совершите радикальную ошибку пятнадцать совершает глубоко? Как вы будете справляться с ветвлением?

По крайней мере, вы должны разделить свою среду на несколько виртуальных экземпляров, но вам действительно нужно делать именно то, что вы сказали, и иметь полностью отдельные экземпляры для каждой среды; в идеале разработка, обеспечение качества, постановка и производство.

В конечном итоге все это наносит огромный ущерб не только вашему фронтальному приложению (и, следовательно, вашей репутации среди пользователей), но и эффективности вашей команды.

Наличие только одного доступного экземпляра Oracle не означает то же самое, что «отсутствие разделения между средами разработки, тестирования и производства»!

Вы написали в комментарии

В настоящее время мы используем разные схемы для разных проектов

Итак, выделив некоторые проекты только для разработки, а некоторые для тестирования, вы можете в некоторой степени отделить свои среды, используя разные схемы. Я думаю, вы уже сделали это, так как это единственный разумный подход, который я знаю, когда не планируется разделение экземпляров. Я не могу представить вашего менеджера настолько безумным, что он хочет, чтобы вы смешивали данные разработчиков, тестовые данные и данные клиентов в одной схеме произвольным образом. Скорее всего, он просто хочет сэкономить, не покупая второй сервер, или вкладывать деньги в лицензию для второго экземпляра.

Поэтому реальный вопрос, который вам нужно задать:

Нужно ли использовать разные экземпляры и / или серверы для разделения сред разработки, тестирования и производства, или достаточно разделения схем?

Это делает ответ не таким четким, как в других ответах здесь. Разные схемы допускают разные права доступа, поэтому вы можете по крайней мере получить некоторую изоляцию в определенной степени внутри одного экземпляра Oracle. Однако вашим разработчикам, скорее всего, потребуются некоторые административные права внутри «их» схемы, поэтому будет сложнее убедиться, что у них не будет доступа к рабочим данным, если вы просто используете один экземпляр.

Более того, один экземпляр / один сервер также будет означать общие ресурсы между dev, test и production - общее администрирование пользователя / схемы, общее дисковое пространство, общие процессоры, общая пропускная способность сети. Объедините это с «законом утечек абстракций» , и будет ясно, что использование только одного экземпляра будет иметь определенный риск получения нежелательных побочных эффектов между средой разработки, тестирования и разработки.

В конце концов, вы должны решить для себя: можете ли вы эффективно работать с недостатками подхода? Является ли ваше приложение не столь ресурсоемким, а ваши производственные данные не настолько «секретными», что допустимо иметь меньший уровень разделения между dev, test и production, чем уровень, который вы получили бы от «трех экземпляров / трех серверов» подходить? Если вы не можете эффективно работать таким образом или нет без высокого риска помешать производству, как вы начинаете терять клиентов, у вас есть все аргументы, необходимые для того, чтобы убедить своего менеджера купить хотя бы второй сервер.

Вам нужно несколько типов среды и, возможно, даже несколько серверов в каждой среде.

Разработчики могут обновить код в разработке. Код может даже не работать - возможно, приложение даже не запустится.

Это не влияет на QA, который тестирует последнюю стабильную сборку в своей среде.

Поскольку и разработка, и QA обновляют свои среды, производство находится на последней версии сборки, выпущенной шесть месяцев назад, и не подвержено изменениям в других средах.

Эти изменения, внедряемые в различных средах, могут быть кодом или данными. Возможно, QA необходимо протестировать сценарий базы данных, предназначенный для исправления некоторых неверных данных в рабочей среде. Возможно, скрипт усугубит проблему - восстановите резервную копию базы данных и попробуйте снова. Если это произойдет на производстве, у вас могут возникнуть серьезные финансовые проблемы.

Что произойдет, если у вас есть несколько выпусков? Возможно, вы разрабатываете версию 2.0, но все еще нуждаетесь в выпусках исправлений ошибок в ветке обслуживания 1.0. Теперь вам нужно несколько сред разработки и контроля качества, чтобы вы всегда могли разрабатывать и тестировать любую ветвь, когда обнаружена критическая ошибка, которую необходимо исправить вчера.

Вы уже заметили , что проблемы не имеющие отдельные среды причины. Тут у вас есть фундаментальная причина для отдельных сред: устранить проблемы, вызванные конфликтами, которые неизбежно возникают при попытке выполнить разработку, тестирование и производственные операции в одной среде. То же самое относится и к тому, чтобы дать разработчикам отдельные песочницы для работы, они не допускают ошибок одного разработчика или даже просто несовместимых изменений, наносящих вред всей команде разработчиков.

Это также лучший аргумент, который вы можете дать руководству для перехода от единой среды: указывать на проблемы, которые уже вызывает единственная среда, показывать линию тренда и утверждать, что рано или поздно, если все продолжится, как есть, будет проблема, которая будет стоить намного дороже (как при непосредственных усилиях, так и из-за утраты уверенности клиентов в способности вашей компании предоставлять услуги), чем перенастройка вещей для отдельных сред.

Здесь много противоборствующих сил и динамики. Существует стоимость наличия множества серверов и стоимость наличия только одного. Я думаю, что этот вопрос может сказать больше, чем просто база данных? Я могу быть недопониманием, но оно относится к системному недоразумению, которое связано с расходами на материальное и абстрактное

Обычно очевидные затраты легко понять.

Абстрактные затраты труднее измерить и, следовательно, труднее понять. Сложнее объяснить TechnicalDebt, стоимость ошибок, стоимость стресса, нагрузку на разработчиков, влияние изменений, регрессионное тестирование, влияние простоев и так далее.

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

Мы используем разные среды для упрощения изменений.

Мы используем разные среды, поэтому мы предлагаем надежность и определенность среды, которая не изменилась.

Мы используем среду, чтобы учесть последствия изменений.

Мы используем среду, чтобы сократить расходы, связанные с изменениями.

Тестирование и стабилизация системы обходятся дорого. Вы создаете среды для защиты инвестиций, вложенных в стабильную среду.

Вы никогда не будете слишком маленькой командой, чтобы придерживаться прагматичных, экономичных, прилежных и проверенных моделей процессов.

Использование одной среды для всего равно, что хранить все свои фотографии на одном жестком диске, вы можете сделать это, но вы будете сожалеть об этом.

некоторые люди нуждаются в доказательстве, что я во многих ситуациях имел дело с клиентами или другими, которые не ценят затраты на обеспечение надежности и следование передовым методам. Я бы предложил вам собрать несколько примеров реальных случаев, когда затраты четко определены.