Цитата:
Сообщение от
Pandasama
Не советую на начальном этапе это применять - есть угроза запутаться самому.
Простая схема
- один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
- VSTS (Azure DevOps) - если программистов больше одного
- один TEST
Посложнее
- один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
- VSTS (Azure DevOps)
- BUILD server
- один TEST
Еще сложнее
- один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
- VSTS (Azure DevOps)
- BUILD server
- один TEST
- один UAT (тоже тестовый сервер)
И еще сложнее, когда версии кода разные для TEST и UAT
- один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
- VSTS (Azure DevOps) - две ветки (branch) DEV и MAIN
- BUILD server - билдить два раза - один раз для DEV, второй раз для MAIN
- один TEST - код из ветки DEV
- один UAT - код из ветки MAIN
Еще сложнее, когда программистов много и не хочется чтобы кто-то зачекинил код, который поломает билд - просто будет ошибка компиляции
- один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
- VSTS (Azure DevOps) - две ветки (branch) DEV и MAIN
- BUILD server - билдить два раза - один раз для DEV, второй раз для MAIN
- на этом же сервере делаем CI (Continuous Integration) Build Definition как клон с обычных, но дизейблим все шаги после Code Build и включаем триггер на каждый чекин
- один TEST - код из ветки DEV
- один UAT - код из ветки MAIN
Для разных проектов - разные настройки и разная сложность инфраструктуры для разработки. Для некоторых решения надо просто дорасти самому проекту.