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

Це було б нормально, за винятком лише одного сервера Apex. Наш менеджер постановив, що все відбувається в одному випадку. Наша команда розробляє додатки, в той час як наш менеджер демонструє їх, і наші внутрішні клієнти використовують їх, що з очевидних причин вже спричиняє проблеми!

Я можу лише очікувати, що це погіршиться, коли ми все більше інвестуємо в Apex, додатки стають складнішими, а кількість користувачів зростає. Я чув, що найкраща практика - це окремі середовища для розробки, тестування та виробництва, але чому це так?

Питання: Чому ми повинні мати окремі середовища розробки, тестування та виробництва?

Чому ми повинні мати окремі середовища розробки, тестування та виробництва?

Ви одночасно проводите кілька заходів:

• розробка - де розробники вводять код, роблять помилки, експериментують тощо ...
• тестування - там, де тести виконуються вручну або автоматизовано, а через складність можуть зайняти багато ресурсів.
• виробництво - там, де цінність створюється для клієнтів та / або бізнесу

Ви хочете, щоб усе це відбувалося в одному середовищі? Ви хочете, щоб бізнес припинився, оскільки новий тест підштовхнув ваші сервери до заміни на жорстких дисках і споживають кожне ядро ​​на процесорі? Ви хочете, щоб ваші тести призупинилися, оскільки розробник зробив згорнуту вилку-бомбу під час експерименту з масштабуванням? Ви хочете, щоб код, який, на вашу думку, спрацював через шпагат розробника та клейку стрічку розробників у тестах для запуску у виробництво? Чи хочете ви, щоб розробники працювали з потенційно чутливими даними про виробництво (я знаю, це не є проблемою для всіх підприємств, але їх у багатьох)?

Що заважає цим питанням траплятися?

Окремі середовища.

То що вам потрібно?

Вам потрібні окремі середовища.

Формально сказати

Вам потрібні окремі середовища з наступних причин:

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

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

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

Я чув, що найкраща практика - це окремі середовища для розробки, тестування та виробництва, але чому це так?

Це не так чітко вирізали ці дні.

У багатьох місцях більше не проводять ручне тестування, тому не майте даних про тестування самі по собі. Багато інших місць мають такий масштаб, що вони не можуть відтворити виробниче середовище через вартість. І особливо при вибухонебезпечному зростанні мікросервісів стає складним утримати швидке зміщення середовища в синхронізації, достатньо для того, щоб тестування в середовищі QA відтворювало речі точно, щоб виявити помилок, які виявляться у виробництві.

Чому ми повинні мати окремі середовища розробки, тестування та виробництва?

• Якщо відвідування ваших даних тесту було б дуже погано.
• Якщо ви отримаєте свої продажні дані, які бачать розробники / тестери, було б дуже погано.
• Якщо ви не можете довіряти своїм розробникам, щоб вони не зламали речі погано, і ви не можете швидко виправити цю ситуацію.
• Якщо у вас є автоматизований ІС на такому рівні, що просування коду відбувається швидко і просто.

По суті, якщо вартість використання середовищ менша за витрати на відсутність середовищ .

Основна (і найбільш очевидна) причина полягає в тому, що ви ніколи не хочете змішувати дані тестування та виробництва. Це може дуже швидко заплутати як користувачів системи, так і розробників. Коли ви керуєте забезпеченням якості та одиничними тестами (що вам слід робити), вам потрібно переконатися, що вони знаходяться в абсолютно відокремленому середовищі. Якщо щось вибухне у вашому середовищі розробки або в якості, це може негативно вплинути на виробництво і, таким чином, живих користувачів та їх важливих даних! Ви абсолютно не хочете, щоб це впливало на виробництво!

Це поширюється на звичайні сервіси, які ви повинні використовувати у своїй щоденній роботі, наприклад, контроль версій. Ви не можете належним чином використовувати контроль версій, якщо код, який ви контролюєте, знаходиться у прямому середовищі! Ваші користувачі стануть божевільними - що робити, якщо вам потрібно повернути або відкати? Що робити, якщо ви зробите різку помилку, що п’ятнадцять здійснює глибину? Як ви впораєтесь із розгалуженням?

Як мінімум, вам слід розділити своє середовище на кілька віртуальних примірників, але вам дійсно потрібно зробити саме те, що ви сказали, і мати абсолютно окремі екземпляри для кожного середовища; в ідеалі розвиток, якість, постановка та виробництво.

Все це в кінцевому підсумку спричиняє величезну шкоду не тільки для вашої передньої програми (і, отже, для вашої репутації у ваших користувачів), але і для ефективності вашої команди.

Наявність лише одного екземпляра Oracle доступне не означає те саме, що "немає поділу між розробниками, тестовими та виробничими середовищами"!

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

В даний час ми використовуємо різні схеми для різних проектів

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

Тому справжнє питання, яке вам потрібно задати, це:

Чи потрібно використовувати різні екземпляри та / або сервери для розділення середовищ розробки, тестування та виробництва, чи достатньо розділення схем?

Це робить відповідь не такою чіткою, як в інших відповідях тут. Різні схеми дозволяють отримати різні права доступу, тому ви можете принаймні отримати певну ізоляцію в певній мірі в одному екземплярі Oracle. Однак вашим розробникам, швидше за все, знадобляться певні адміністративні права всередині "своєї" схеми, тому буде важче переконатися, що вони не матимуть доступу до виробничих даних, якщо ви просто використовуєте один екземпляр.

Більше того, один екземпляр / один сервер також означатиме спільні ресурси між розробником, тестом та виробництвом - спільне адміністрування користувача / схеми, спільний дисковий простір, спільні процесори, спільна пропускна здатність мережі. Поєднайте це із "законом протікаючих абстракцій" , і буде зрозуміло, що використання лише одного екземпляра матиме певний ризик отримати небажані побічні ефекти між середовищем розробки, тесту та продукту.

Зрештою, ви повинні вирішити для себе: чи зможете ви ефективно працювати з недоліками підходу? Ваш додаток не настільки ресурсомісткий, а ваші виробничі дані не настільки "секретні", що допустимо мати знижений рівень поділу між розробником, тестом та виробництвом, ніж рівень, який ви отримаєте від "трьох екземплярів / трьох серверів" підхід? Якщо ви не можете ефективно працювати таким чином чи не без високого ризику втручатися у виробництво таким чином, що ви починаєте втрачати клієнтів, у вас є всі аргументи, які вам потрібні, щоб переконати свого менеджера купити хоча б другий сервер.

Вам потрібно кілька типів середовища і, можливо, навіть декілька серверів у кожному середовищі.

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

Це не впливає на контроль якості, який тестує останню стабільну конструкцію у власному середовищі.

Оскільки і розробка, і QA оновлюють своє середовище, виробництво на останній версії випущено з півроку тому, і зміни на інших середовищах не впливають.

Ці зміни, що впроваджуються в різних середовищах, можуть бути кодом або даними. Можливо, QA потребує тестування сценарію бази даних, призначеного для виправлення поганих даних у виробництві. Можливо, сценарій ще більше погіршує проблему - відновіть резервну копію бази даних та повторіть спробу. Якби це сталося у виробництві, у вас може виникнути дуже серйозна фінансова проблема.

Що станеться, якщо у вас є кілька релізів? Можливо, ви розробляєте версію 2.0, але все ж потрібні виправлення помилок у відділенні обслуговування 1.0. Тепер вам потрібно багаторазове середовище розробки та забезпечення якості, щоб завжди можна було розробити та протестувати будь-яку гілку, коли виявлена ​​критична помилка та її потрібно виправити вчора.

Ви вже помітили проблеми, які не мають окремих середовищ. Саме там у вас є основна причина для окремих середовищ: усунути проблеми, викликані конфліктами, які неминуче виникають при спробі зробити операції з розробки, тестування та виробництва в єдиному середовищі. Це ж міркування стосується надання розробникам індивідуальних пісочниць для роботи, вони зберігають помилки одного розробника або навіть не сумісні зміни від каліки всієї команди розробників.

Це також найкращий аргумент, який ви можете зробити керівництву за те, щоб відмовитися від єдиного оточення: вказуючи на проблеми, які вже викликає одне середовище, показуючи лінію тренду і аргументуючи це рано чи пізно, якщо все триватиме так, як вони є, буде Проблема, яка буде коштувати набагато дорожче (як прямі зусилля, так і втрачена впевненість клієнтів у здатності вашої компанії надавати послуги), ніж перенастроювання речей для окремих середовищ коштуватиме.

Існує багато протилежних сил і динаміки. Існує вартість наявності багатьох серверів і вартість лише одного. Я думаю, що це питання може розширитись, ніж просто база даних? Я можу нерозуміти, але це стосується системного непорозуміння, яке там переоцінює матеріальне та абстрактне

Зазвичай очевидні витрати легко зрозуміти.

Абстрактні витрати важче кількісно оцінити і, таким чином, важче зрозуміти. Технічний заборгованість, вартість помилок, вартість стресу, навантаження на розробників, наслідки змін, тестування регресії, вплив простоїв і так далі важче пояснити.

різні середовища Середовища зазвичай розділені для даних та / або цілей. Кожне середовище має різні функції. Швидкість зміни в системі, тобто. як часто воно буде оновлюватися, які зміни та наслідки змін розглядаються.

Ми використовуємо різні середовища, щоб домогтися змін.

Ми використовуємо різні середовища, тому пропонуємо надійність та визначеність середовища, яке не змінилося.

Ми використовуємо середовища для розгляду наслідків змін.

Ми використовуємо середовища, щоб зменшити витрати, пов'язані зі змінами.

це коштує багато для тестування та стабілізації системи. Ви створюєте середовища, щоб забезпечити інвестиції, зроблені в стабільне середовище.

Ви ніколи не занадто мала команда, щоб дотримуватися прагматичних, економія витрат, старанних і перевірених моделей процесу.

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

Деякі люди потребують доказів. Я був у багатьох ситуаціях, маючи справу з клієнтами чи іншими, хто не оцінює витрати на забезпечення надійності та дотримання найкращих практик. Я б запропонував скласти кілька прикладів реальних випадків, коли витрати чітко визначені.