Как нынче модно проекты с локального сервера на боевой заливать?

Question

[SvizzZzy]

Приветствую.
Я обычно работаю оди, над своими проектами и делаю это по старинке - с заменой файлов по FTP.
Это конечно вызывает перебои в работе сайтов, когда обновляются важные для работы сайта файлы :)
Догадываюсь, что сейчас в 2017 это делается по другому.

Поверхностно знаком с GIT, почитал некоторую инфу.
Пытаюсь понять как происходит процесс заливки целого проекта (включая картинки и тд) на рабочий сервер.

Пока сложилась такая картина:
(Допустим, разработчик один, без команды)

1. Кодишь себе на локальной машине, кодишь.. кодишь..
2. (Пулишь?) свой проект в репозиторий на github
3. Подключаешься к серверу через SSH и выполняешь там что-то вроде git clone репозитория с github

Общий смысл верный или есть какие-то особенности ?
Может для этого вообще не GIT используется ?

Comments

[Толстый Лорри]

Не стоит микроскопом гвозди забивать! Деплоить с гита - это не просто колхоз, но еще и опасно. Для этого есть специальные инструменты - CI.

Answer 1

[Станислав Катков]

CI это конечно круто, вы наверно к этому должны стремиться. Но для маленьких проектов я использую вот этот замечательный инструмент mina -> https://github.com/mina-deploy/mina

1. Вы описываете конфигурационный файл в руби (там впринцепи, легкий такой для понимания DSL)
2. он потом генерить bash script, куча полезных фич просто из коробки -- откатывать релиз можно, запускать процессы, выключать, перезагружать и так далее.
3. загружаешь скрипт на сервер и запускаешь - он там сам развертывает релиз

дальше уже дело техники, как вы этот релиз доставлять будете - можно с помощью git'a, как вы уже сказали. а можно tarball какой-нибудь на сервак лить, и оттуда раздавать... Все зависит от вашего кейса, величины проекта и какой инструментарий вы используете :)

Answer 2

[Максим Федоров]

Чтобы не спугнуться — пишу свой опыт, я как раз между советами выше и твоим уровнем. Вот по порядку мой путь.

Первый этап — познаем Гит:

• Создаешь репозиторий на Гите для проекта
  
• Разворачиваешь локальный проект и удаленный
  
• Сделал доработку — git push origin master — отправка в репозиторий изменений
  
• Подтягиваем изменения на удаленном dev-сервере — git pull origin master
  

Минусы:
— если что-то не то, постоянно нужно на горячую делать изменения, ветка (она одна у тебя) всегда не стабильная
— руками нужно менять миграции/БД и прочее, докачивать зависимости composer

Второй этап (на котором я нахожусь):

1. Добавляем ветвления, создаем ветку dev
   
2. Создаем второй сайт на поддомене dev.domain.ru
   
3. Всю работу делаем на дев-ветке и пушим ее же, по возможности добавляем ветки под каждую задачу и мерджим (или через пулл-реквесты) сливаем в дев, првоеряем всю работу на дев-севрере
   
4. Мерджим в master ветку стабильню dev-ветку
   

Минусы:
— руками нужно менять миграции/БД и прочее, докачивать зависимости composer

Третий этап (скоро освою):

• Разбираемся с CI
  
• Чтобы миграции и все зависимости автоматом после git pull сами подтягивались, был откат на предыдущее состояние, особенно касательно БД это важно
  

Например сейчас уже делаю bash-скрипт, чтобы фикстуры все мне тянул одновременно :)
Начни потихоньку, чтобы проникнуться особенностями версий... освоить команды GIT, у тебя всплывут вопрос из разряда "как переделать последний коммит", "как удалить папку в репозитории" и т.д... потом уже усложнишь — усложняют из-за того, что работа идет командная, один можешь на 1 этапе сидеть, но лучше и одному не сидеть там :)

Answer 3

[n-fom]

Continuous Integration