Стандарты именования среды в разработке программного обеспечения?

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

Термины включают «Local», «Sand», «Dev», «Test», «User», «QA», «Staging» и «Prod» (плюс еще несколько, о которых спрашивали разные люди)

Я не ищу только мнения, хотя, если есть кто-то, что есть у «каждого», я возьму это - я пытаюсь найти определения, выдвинутые какой-то властью, даже если это неофициально.

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

1. Среда на ПК разработчика
2. Общая среда, где разработчики напрямую загружают код для самопроверки
3. Общая среда, в которой стандарты и функциональные возможности проверяются специалистами по обеспечению качества
4. Общая среда, в которой завершен и проверен QA-код, утвержден заказчиками проекта
5. Среда, которая отражает окончательную среду как окончательную проверку и подготовку к развертыванию
6. Конечная среда, в которой используется код

Я знаю, как бы я их назвал, но есть ли какой-то стандарт на это? Заранее спасибо.

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

Я работал всего с одной средой и целых 13.

В последовательности, которую вы описываете, я обычно вижу, что они называют их что-то вроде

1. локальный или dev, если вы не используете dev на следующем шаге
2. Dev или интеграция, если это первое развертывание после слияния
3. тест или QA
4. UAT или принятие или QA, если вы не использовали QA на шаге 3
5. pre-prod, staging или performance, если это шаг производительности для окончательного завершения
6. тычок

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

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

Если вы ищете имена самих серверов, я обычно предлагаю называть их по полномочиям. Обычно это выглядит примерно так:

• разработчики могут манипулировать разработчиками
• Разработчики не могут манипулировать машинами контроля качества, но также не контролируются производственной поддержкой
• прод машины являются бизнесом поддержки прод

большинство людей заканчивают тем, что используют такие имена в качестве префиксов или суффиксов, чтобы у вас была цепочка вроде «devsqllweb», «qasqlweb», «prodsqlweb» или что-то в этом роде.

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

То, что мы сделали, прошли путь DNS-имен и псевдонимов. Правило первой буквы определяет общую роль сервера в процессе разработки (зона)

• р = производство
• d = развитие
• s = постановка
• т = тестирование

Тогда у нас есть максимум три буквы имени, чтобы определить роль машины

• приложение = приложение
• дБ = база данных
• веб = веб- интерфейс / веб
• kas = кеширование

За ним следует цифра, если в этой зоне несколько машин. Мы публикуем это на внутреннем сервере документации и предоставляем как часть новой документации для проектов и на этапе начальной загрузки.

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

Это привело к некоторым интересным из них, два моих любимых - это cerberus (внутренний прокси) box и hades (сервер документации / интранет)

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

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

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