Екологічні стандарти іменування в розробці програмного забезпечення?

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

Терміни включають в себе "Місцевий", "Пісок", "Dev", "Тест", "Користувач", "QA", "Постановка" і "Прод" (плюс ще кілька, про які розпитували різні люди)

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

Ось такі середовища, які ми зараз використовуємо:

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

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

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

Я працював із якоюсь меншою мірою одним середовищем і аж 13.

У послідовності, яку ви описуєте, я, як правило, бачу, як вони їх називають чимось подібним

1. local або dev, якщо ви не використовуєте dev на наступному кроці
2. dev або інтеграція, якщо це перший розгортання після злиття
3. тест або QA
4. uat або приймання або QA, якщо ви не використовували QA на кроці 3
5. попередній показ, постановка або виконання, якщо це етап ефективності для остаточного відходу
6. прод

Моя порада полягатиме в тому, щоб домовитись про назви, цілі та критерії, щоб увійти та залишити кожен для кожного продукту чи проекту, тоді, коли ви зрозумієте, що вам потрібно 7-е середовище або лише 5 в одному випадку з іншої причини, в майбутньому знову обговоріть із команда.

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

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

• Девізними машинами можуть маніпулювати розробники
• Машини якості забезпечення не можуть управляти розробниками, але також не контролюються виробничою підтримкою
• Машини prod - це підтримка prod

більшість людей в кінцевому підсумку використовують такі види імен як префікси або суфікси, щоб у вас був ланцюжок на зразок "devsqllweb" "qasqlweb" "prodsqlweb" або щось подібне.

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

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

• p = виробництво
• d = розвиток
• s = постановка
• t = тестування

Тоді ми маємо максимум три букви, щоб визначити роль машини

• app = додаток
• db = база даних
• web = frontend / web
• kas = кешування

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

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

Це призвело до декількох цікавих, мої два улюблені - це поле cerberus (внутрішній проксі) та хаде (сервер документації / інтранет)

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

Фіксованого визначення немає. Є декілька, які використовуються загальною практикою (яку ви перерахували). Якщо ви хочете дати кожному середовищу ім’я персонажа в Історії іграшок, ви можете (не рекомендуватиму це, хоча).

Що я б робив, це створити словник компанії, в якому ми б давали імена, які ми хотіли б використати.