Как работает развертывание на удаленных серверах?
Я немного новичок в контроля версий и сред развертывания и я остановился в своем изучении этого вопроса: как работают среды развертывания, если разработчики не могут работать на одной локальной машине и вынуждены всегда работать на удаленный сервер?
Как поток среды развертывания настраиваются в соответствии с лучшими практиками?
для этого примера я рассмотрел три среды развертывания: развитие, постановка и производства; и три условия хранения: local, хранилище сервер и заключительный сервер.
Это блок-схема, которую я придумал, но я понятия не имею, правильно ли это или Как правильно ее реализовать:
PS. Я думал, что промежуточные тесты на сервере могут иметь ограниченный доступ через логин или ip-проверки, в случае, если вам интересно.
1 ответов
я могу дать вам (по моему опыту) хорошую и прямолинейную практику, это не единственный подход, так как нет уникального стандарта о том, как работать на всех проектах:
- 
используйте распределенную систему управления версиями (например, git/ github): - сделать частный/публичный репозиторий для обработки вашего проекта
 
- 
местное развитие: - разработчики будут colne проект из вашего РЕПО и внести свой вклад в него, рекомендуется, чтобы каждый из них работал на ветке, и создать новую ветку для каждой новой функции
- в вашей команде есть один ответственный за слияние ветвей, которые готовы с masterфилиала
- я настоятельно рекомендую работать на виртуальной машине во время разработки:
- чтобы изолировать среду dev от хост-машины и иметь дело с зависимостями
- чтобы иметь виртуальную машину, идентичную удаленный рабочий сервер
- легко сбросить, удалить, воспроизвести
- ...
- я предлагаю использовать VirtualBox для провайдера VM и залетный для подготовки
- я предлагаю, чтобы ваша папка проекта была shared folderмежду вашим хостом и виртуальной машиной, так вы будете писать исходный код на хост-ОС с помощью редактора вы любите, и в то же время этот кодекс существует и работает внутри виртуальной машины, это не так удивительно круто ?!
 
- если вы работаете с pythonЯ также настоятельно рекомендую использовать виртуальные среды (например,virtualenv или анаконда) для изоляции и управления внутренними зависимостями
- затем каждый разработчик после написания некоторого исходного кода может зафиксировать и протолкнуть свои изменения в репозиторий
- я предлагаю использовать Инструменты Настройки автоматизации проектов, такие как (ткани/fabtools для Python):
- создание скрипта или чего-то, что одним щелчком мыши или некоторыми командами воспроизводит всю среду и все зависимости и все, что необходимо для проекта, чтобы быть запущенным, поэтому все разработчики бэкэнд, интерфейс, дизайнеры... независимо от того, их knowlege или их типы хост-машин могут заставить проект работать очень просто. Я также предлагаю сделать то же самое с удаленными серверами вручную или с помощью таких инструментов, как (ткань/fabtools)
Secript будет в основном установите зависимости ОС, затем зависимости проекта, затем клонируйте РЕПО проекта из вашего элемента управления Virsion, и для этого вам нужно предоставить удаленным серверам (тестирование, постановка и производство) доступ к репозиторию: добавьте открытые ключи ssh каждого сервера к ключам в вашей системе управления версиями (или используйте агент переадресации с fabric)
 
- создание скрипта или чего-то, что одним щелчком мыши или некоторыми командами воспроизводит всю среду и все зависимости и все, что необходимо для проекта, чтобы быть запущенным, поэтому все разработчики бэкэнд, интерфейс, дизайнеры... независимо от того, их knowlege или их типы хост-машин могут заставить проект работать очень просто. Я также предлагаю сделать то же самое с удаленными серверами вручную или с помощью таких инструментов, как (ткань/fabtools)
Secript будет в основном установите зависимости ОС, затем зависимости проекта, затем клонируйте РЕПО проекта из вашего элемента управления Virsion, и для этого вам нужно предоставить удаленным серверам (тестирование, постановка и производство) доступ к репозиторию: добавьте открытые ключи ssh каждого сервера к ключам в вашей системе управления версиями (или используйте агент переадресации с 
 
- 
удаленного сервера: - вам понадобится по крайней мере производственный сервер, который делает ваш проект доступным для конечных пользователей
- рекомендуется, чтобы у вас также были тестовые и промежуточные серверы (я полагаю, что вы знаете цель каждого из них)
 
- 
поток развертывания: локальный-РЕПО-удаленный сервер, как он работает ?: - дайте удаленным серверам (тестирование, постановка и производство) доступ к репозиторию: добавьте открытые ключи ssh каждого сервера к ключам в вашей системе управления версиями система (или переадресация агента пользователя с fabric)
- разработчик пишет код на своей машине
- в конце концов пишет тесты для своего кода и запускает их локально (и на сервере тестирования)
- devloper фиксирует и нажимает свой код на ветку, которую он использует для удаленного репозитория
- 
развертывание: 5.1 если вы хотите развернуть ветвь функций для тестирования или постановки: - 
sshоткрыть на сервер, а затемcdв папку проекта (клонированный из РЕПО вручную или скриптом autamtion)
- git checkout <the branch used>
- git pull origin <the branch used>
 5.2 если вы хотите развернуть в производство: - сделать pull requestи после того, как запрос pull будет проверен менеджером и объединен сmasterфилиала
- 
sshдоступ к серверу, а потомcdв папку проекта (клонированный из РЕПО вручную или скрипт автоматизации)
- 
git checkout master# не требуется, потому что он всегда должен быть на master
- 
git pull origin master- я предлагаю написать сценарий, как с тканью / fabtools или использовать инструменты, такие как Дженкинс для автоматизации задачи развертывания. Вуаля ! Сделано развертывания !
 
 
- 
 
- дайте удаленным серверам (тестирование, постановка и производство) доступ к репозиторию: добавьте открытые ключи ssh каждого сервера к ключам в вашей системе управления версиями система (или переадресация агента пользователя с 
это немного упрощенный подход, есть еще куча других рекомендуемых и лучших инструментов prectice и задачи.
 
            