Меню Рубрики

Установка git на хостинге

Работа с Git на хостинге

Что такое Git?

Git — система контроля версий, которая позволяет хранить и отслеживать все изменения, внесённые в файлы, а также предоставляет возможность работать над одним проектом нескольким разработчикам.

Для создания проекта (например, сайта) с использованием Git вам понадобится:

Локальный репозиторий — хранилище Git на локальном компьютере. Вы работаете над проектом на своём рабочем компьютере, сохраняете свои изменения в локальный репозиторий с помощью коммита (commit), а затем помещаете (push) свои изменения в удалённый репозиторий. Если над проектом работают несколько разработчиков, у каждого свой локальный репозиторий.

Удалённый репозиторий — система управления репозиториями кода для Git. Например: GitHub, GitLab, Bitbucket. После завершения локальной работы над кодом каждый разработчик проекта отправляет свою часть кода или изменения в удалённый репозиторий, где всё сливается (merge) воедино, а затем разворачивается (deploy) на сервер проекта.

Сервер проекта — это виртуальный хостинг, VPS или любой другой сервер. Развернуть свой проект можно несколькими способами. Существуют системы автоматического развёртывания из удалённого репозитория, а также ручное клонирование с помощью Git.

На хостинге REG.RU установлен Git, благодаря чему вы сможете упростить процесс разработки и публикации сайта. Обратите внимание: на хостинге REG.RU по умолчанию используется Git версии 1.7.1. Для запуска версии 2.19.2 используйте алиас git2192.

Ниже рассмотрим, как поместить код в удалённый репозиторий на примере GitHub и как клонировать файлы на услугу хостинга.

Подготовка к работе

Для работы вам необходимо скачать Git с официального сайта и установить на свой локальный компьютер. Для пользователей Linux Git, как правило, доступен из коробки. Для пользователей Windows рекомендуем использовать графические оболочки, например SmartGit или GitKraken.

Работа с Git происходит через терминал. Если у вас нет локального репозитория, создайте его в каталоге проекта с помощью команды git init

Файлы, которые необходимо отправить в удалённый репозиторий, добавьте с помощью команды git add каталог/название_файла или же выполните команду git add . , чтобы добавить все папки и файлы, которые находятся каталоге вашего проекта.

Создайте коммит с помощью команды

Готово. Вы создали репозиторий, добавили туда файлы проекта и сделали свой первый коммит. Подробнее о работе с Git, создании веток, слиянии, откате изменений и прочих командах вы можете узнать в официальной документации.

Отправка изменений в удалённый репозиторий

Все команды будут выстроены на примере работы с GitHub. Работа с другими хранилищами репозитория происходит аналогично.

На локальном компьютере, в терминале, добавьте ссылку удалённого репозитория с помощью команды:

Затем отправьте изменения в удалённый репозиторий с помощью команды:

Система запросит ваш логин и пароль от GitHub.

Готово. После завершения отправки ваши файлы появятся в удалённом репозитории на GitHub.

Публикация сайта с GitHub на хостинг

Чтобы клонировать изменения с GitHub на хостинг REG.RU:

Важно: в конце команды стояла точка, это нужно для копирования самих файлов из репозитория в корневой каталог. Иначе в корневой каталог будет загружен каталог репозитория, а уже затем в него сами файлы.

В дальнейшем вместо команды из 3 шага вы можете выполнить команду git pull , которая будет синхронизировать файлы на хостинге с файлами из репозитория.

Готово. Теперь вы можете работать над проектом локально, сохранять свои изменения в удалённом репозитории, а затем публиковать их на хостинг.

источник

Как настроить Git на виртуальном хостинге

Когда вы используете Git в разработке, загружать новую версию сайта на хостинг всё равно приходится вручную. Нужно каждый раз подключаться к FTP-серверу, переходить в нужную папку, перетаскивать в неё файлы. Но если подключить Git к хостингу, обновлять сайт можно будет одной кнопкой в cPanel или командой в консоли. Как это сделать — расскажем в статье.

Создаём репозиторий в cPanel

Зайдите в cPanel и нажмите ярлык «Git™ Version Control» в разделе «Файлы»:

Пока что тут пусто. Чтобы создать первый репозиторий, нажмите кнопку «Создать» в правой части экрана.

В новом окне заполните поля данными, которые указывают на ваш репозиторий:

Clone URL — ссылка на репозиторий с вашим проектом с любого сервиса по работе с git-репозиториями, например, github.com, gitlab.com, bitbucket.org.

Repository Path — путь к репозиторию в cPanel. Сюда будут загружаться файлы с сайтом. Здесь можно указать корневую папку домена или любую другую. Главное, чтобы папка была пустой, иначе назначить её репозиторием не получится.

Repository Name — имя репозитория. Оно будет отображаться в общем списке репозиториев. Сюда можно вписать что угодно, например, домен, для которого вы разрабатываете сайт.

В конце нажмите кнопку «Создать». Репозиторий появится в общей таблице:

Загружаем изменения из удалённого репозитория на хостинг

Когда понадобится обновить файлы с сайтом на хостинге, нажмите кнопку «Управлять» напротив нужного репозитория и на следующей странице нажмите «Обновление»:

После этого файлы из репозитория на сайте системы контроля версий загрузятся в репозиторий в cPanel.

На этой же странице вы найдёте информацию о последней активности в репозитории:

Currently Checked-Out Branch — ветка, из которой в последний раз копировали изменения.

HEAD Commit — информация о последнем коммите: хэш позиции, автор и дата.

Remote URL — ссылка на репозиторий на сайте системы контроля версий.

Clone URL — ссылка для скачивания репозитория по SSH.

Настраиваем автоматическое обновление сайта из репозитория

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

Чтобы автоматизировать этот процесс, создайте в корне репозитория на стороне cPanel файл с названием .cpanel.yml и добавьте в него такой текст:

Не забудьте прописать правильный путь в строке «export DEPLOYPATH».

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

Управляем репозиторием в консоли

Чтобы не заходить каждый раз в cPanel ради изменений, подключитесь к серверу по SSH и управляйте репозиторием в cPanel через консоль. Вам пригодятся такие команды:

git checkout название_ветки Переключиться на другую ветку из удалённого репозитория. По умолчанию cPanel будет знать только о ветке master, даже если на стороне системы контроля версий их несколько.
git pull Загрузить изменения из ветки, в которой вы находитесь. Команда работает так же, как и кнопка «Обновление» в cPanel.
git log —all —decorate —oneline —graph Посмотреть историю всех коммитов в удобном формате.
git revert идентификатор_коммита Откатить репозиторий на стороне cPanel до конкретного коммита.
git clone ssh://ссылка Загрузить текущую версию кода на компьютер. Ссылку можно найти в меню «Git™ Version Control» – «Управлять».

Документация на русском языке

Больше информации по использованию системы контроля версий — в русскоязычном учебнике на сайте Git.

источник

Создание, настройка и использование собственного Git-сервера

Материал, перевод которого мы сегодня публикуем, посвящён настройке Git-серверов. Git — это система управления версиями, разработанная Линусом Торвальдсом. Git пользуются миллионы людей во всём мире. Компании, вроде GitHub, предлагают службы хостинга кода, основанные на Git. По информации, которую можно найти в различных публикациях, GitHub является крупнейшим сервисом для хостинга IT-проектов. В частности, в 2017-м году сообщество GitHub достигло 24 миллионов разработчиков, которые трудятся над 67 миллионами репозиториев. В наши дни GitHub пользуются абсолютно все — от программистов-одиночек, до крупных организаций. Надо сказать, что даже компания Google перешла на GitHub, закрыв собственный проект схожей направленности.

Читайте также:  Установка коллиматора на хатсан 125

Зачем нужен собственный Git-сервер?

GitHub — это замечательный сервис, но, особенно если вы — индивидуальный разработчик или небольшая компания, вы, при работе с GitHub, столкнётесь с некоторыми ограничениями. Одно из них заключается в том, что в бесплатный пакет услуг не входит хостинг приватных репозиториев. За эту возможность придётся заплатить, как минимум, $7 в месяц.

В подобных ситуациях, для того, чтобы обойти ограничения, или если вам нужно контролировать то, что происходит с вашими репозиториями, лучше всего создать собственный Git-сервер. Это, с одной стороны, поможет сэкономить, а с другой — даст полный контроль над сервером. Среди продвинутых пользователей Linux весьма распространена практика использования собственных Git-серверов, размещаемых, можно сказать, бесплатно, на уже используемых ими серверах.

В этом руководстве мы поговорим о двух подходах к управлению кодовой базой с использованием собственного Git-сервера. Первый заключается в использовании обычного Git-сервера, а второй — в применении инструмента с графическим интерфейсом GitLab. В качестве платформы для экспериментов тут используется сервер на полностью пропатченной Ubuntu 14.04 LTS, развёрнутый на VPS.

Использование Git

Здесь мы рассматриваем сценарий, в соответствии с которым у нас имеется удалённый сервер и локальный сервер. Работаем мы периодически то с одним, то с другим.

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

Затем добавим пользователя для Git:

Для того чтобы упростить доступ к удалённому серверу, настроим вход по ssh без пароля.

Создадим ssh-ключи на локальном компьютере:

Система спросит у вас о том, куда нужно сохранить ключ. Если вас устраивает стандартное место хранения ключа, просто нажмите Enter. Далее вам предложат задать пароль, который будет нужен для доступа к удалённому серверу.

Вышеописанная команда генерирует два ключа — открытый и закрытый. Запишите или запомните расположение открытого ключа. Он понадобится нам на следующем шаге.

Теперь надо скопировать эти ключи на сервер, что даст возможность наладить канал связи между двумя машинами. На локальном компьютере выполните следующую команду:

Теперь подключитесь по ssh к серверу и создайте директорию проекта для Git. Для репозитория можно использовать любую папку, которая покажется вам подходящей:

Затем перейдите в эту директорию:

Создайте пустой репозиторий:

Если команда успешно сработала, вы увидите сообщение, подобное следующему:

Теперь нужно создать Git-репозиторий на локальной машине. Для этого создаём директорию:

Далее, создаём в ней файлы проекта, и, оставаясь в ней, инициализируем репозиторий:

Об успешной инициализации репозитория можно судить по такому сообщению:

Теперь добавим файлы проекта в репозиторий:

С этого момента, после добавления в проект новых файлов или после изменения существующих, нужно будет выполнять вышеописанную команду ( git add . ). Кроме того, нужно будет выполнять команду git commit , задавая сообщения, описывающие коммиты. Выглядит это примерно так:

В нашем случае здесь имеется файл, который называется GoT (в нём лежит текст обзора Game of Thrones), в который внесены некоторые изменения. Изменения внесены и в другой файл. Поэтому при выполнении команды система сообщила о том, какие изменения были внесены в файлы. В вышеописанной команде опция -a означает обработку всех файлов репозитория. Если вы внесли изменения лишь в один файл, можно, вместо опции -a , указать имя этого файла.

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

Теперь можно отправлять изменения с локальной машины на сервер или загружать данные с сервера, используя, соответственно, опции push или pull :

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

В данной команде /home/swapnil/project.git — это путь к папке проекта на удалённом сервере, в вашем случае тут будет другой путь.

Затем, после клонирования, надо перейти в директорию проекта:

У вас, вместо project будет имя другой директории. Теперь можно приступать к работе над проектом, принимать изменения и отправлять их на сервер:

Мы полагаем, что вышеприведённых сведений достаточно для того, чтобы помочь тем, у кого не было опыта работы с Git, приступить к использованию собственного Git-сервера. Если вам нужен некий инструмент с графическим интерфейсом, позволяющий работать с проектом на локальной машине, можно воспользоваться чем-то вроде QGit или GitK для Linux.

QGit — графический инструмент для локальной работы с Git-репозиториями

Использование GitLab

Выше мы описали систему, позволяющую организовать совместную работу над проектами с помощью Git, полностью основанную на средствах командной строки. Работать в такой среде, конечно, сложнее, чем с GitHub. По иронии судьбы, хотя GitHub — это крупнейший в мире сервис для хостинга кода, его собственный код закрыт. Это — не опенсорсный проект, то есть, нельзя взять этот код и создать на его основе собственный GitHub. В отличие от чего-то вроде WordPress и Drupal, код GitHub нельзя загрузить и развернуть на собственном сервере.

Но, как это обычно бывает в мире опенсорса, проектам с закрытым кодом можно найти замену. В данном случае заменой GitHub может послужить весьма привлекательный опенсорсный проект GitLab. Он позволяет всем желающим разворачивать на собственных серверах нечто подобное GitHub. При этом GitLab можно использовать и для поддержки работы крупной компании или большой команды, и для организации собственного репозитория для небольшого проекта, который пока не готов к тому, чтобы представить его широкой общественности.

GitLab задействует бизнес-модель, характерную для опенсорсных проектов. А именно, имеется свободно распространяемая версия ПО, которую все желающие могут разворачивать на своих серверах, и хостинг кода, похожий на GitHub.

Свободно распространяемая версия GitLab имеет две редакции — бесплатную Community Edition (Core) и платную Enterprise Edition (существуют её варианты Starter, Premium и Ultimate). Последняя основана на Community Edition, которая отлично масштабируется, и, кроме того, включает в себя некоторые дополнительные возможности, ориентированные на организации. Это немного напоминает позиционирование WordPress.org и WordPress.com.

Среди возможностей GitLab можно отметить управление Git-репозиториями, средства обзора кода, наличие системы отслеживания ошибок, ленты активности, поддержку вики-страниц. Здесь имеется и GitLab CI — система непрерывной интеграции.

Многие VPS-провайдеры, вроде DigitalOcean, предлагают пользователям дроплеты GitLab. Если вы хотите развернуть GitLab на собственном сервере, вы можете установить эту систему вручную. GitLab предлагает пакет Omnibus для различных операционных систем. Прежде чем установить GitLab, может возникнуть необходимость в настройке почтового SMTP-сервера для того, чтобы система могла отправлять электронную почту. Рекомендовано для этих целей пользоваться Postfix. Поэтому, перед установкой GitLab, установим Postfix:

В процессе установки Postfix система задаст вам несколько вопросов. Не стоит пропускать ответы на них, но если ответы на них не даны, можно перенастроить систему, выполнив следующую команду:

Читайте также:  Установка cwm recovery на кирпич

После запуска этой команды нужно указать параметр Internet Site и задать почтовый идентификатор для домена, который будет использоваться GitLab. Далее, надо будет указать имя пользователя для Postfix и почтовый адрес. Значения остальных параметров можно не менять. После установки и настройки Postfix можно заняться GitLab.

Загрузим свежий пакет отсюда с помощью wget :

Настроим и запустим GitLab:

Теперь надо будет настроить доменное имя в конфигурационном файле, что даст возможность работать с GitLab. Откроем файл:

В этом файле надо будет отредактировать параметр external_url , указав здесь доменное имя сервера. После редактирования файла его надо сохранить, после чего только что созданный GitLab-сайт можно открыть в браузере.

Сайт GitLab, открытый в браузере

По умолчанию система создаёт учётную запись администратора с именем root и паролем 5iveL!fe . Сразу после первого входа на сайт следует поменять пароль.

Смена пароля на сайте GitLab

После того, как пароль изменён, можно войти на сайт и заняться работой с проектами.

Работа с проектами в GitLab

GitLab — это серьёзная система, имеющая массу возможностей. Как в них разобраться? Позволим себе привести тут несколько изменённую цитату из фильма «Матрица»: «Увы, невозможно рассказать о том, что умеет GitLab. Вы должны увидеть это сами».

Уважаемые читатели! Пользуетесь ли вы собственными Git-серверами? Если да — просим рассказать о том, как вы их настраиваете и поддерживаете.

источник

Git и публикация сайта

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

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

Основные преимущества:

  • Делая push из удалённой копии мы автоматически обновляем live-копию сайта
  • Правки файлов на сервере не будут разрушать историю коммитов
  • Простота, не нужны особые правила выполнения коммитов
  • Можно применить к уже запущенному сайту, без повторного деплоя или перемещения файлов

Обзор

Главная идея системы — создение на сервере двух репозиториев: пустого bare-репозитория и обычного репозитория с рабочей копией сайта. Эта пара связана парой простых хуков, которые автоматизируют push и pull изменений.

Итак, два репозитория:

  • Hub — bare-репозиторий. Все репозитории разработчиков клонируются именно от него.
  • Prime — обычный репозиторий. Сайт запускается из рабочего каталога этого репозитория.

Работа с двумя репозиториями простая и очень гибкая. Удалённые копии, имеющие ssh-доступ могут легко обновлять live-версию сайта просто выполнив push в Hub-репозиторий. Любые изменения, выполненные в live-версии на сервере мгновенно вливаются в Hub при коммите. В общем, всё работает очень просто — и неважно, где делаются изменения.

Небольшие приготовления перед стартом

Естественно, в первую очередь нужно, что бы Git был установлен на сервере и на всех компах разработчиков. Если на вашем shared-хостинге не установлен Git — вы очень легко можете это исправить (en).

Если вы первый раз работаете с Git на своём сервере, не забудьте указать глобальные настройки. Я указываю особое значения для user.name, чтобы потом видеть в истории проекта изменения, выполненные на сервере:

$ git config —global user.name «Джо, фигачу на сервере»

Поехали!

/www
$ git init
$ git add .
$ git commit -m «Импорт всех существующих файлов сайта»

Поскольку мы сделали инициализацию репозитория в рабочей копии – нет нужды отключать сайт на обслуживание и повторно выкладывать все файлы, Git просто содаст репозиторий из имеющихся файлов.

Теперь, когда наш сайт уже находится в Git, создадим bare-репозиторий где-нибудь вне рабочего каталога сайта.

$ cd
$ mkdir site_hub.git
$ cd site_hub.git
$ git —bare init
Initialized empty Git repository in /home/joe/site_hub.git

/site_hub.git
$ git remote show hub
* remote hub
URL: /home/joe/site_hub.git
$ git push hub master

Как я уже упоминал в начале, Hub и Prime синхронизируются между собой, используя два простых скрипта.

Одно из основных правил при работе с Git — никогда не делайте push в репозтирий, у которого есть рабочая копия. Мы следуем этому правилу и создали репозиторий «Hub». Вместо того, чтобы делать push из Hub, который никак не повлияет на рабочую копию, мы будем использовать хук, который заставит Prime выполнить pull из Hub-репозитория.

Post-update — в Hub-репозитории

echo
echo «**** Вытягиваем изменения в Prime [Hub’s post-update hook]»
echo

cd $HOME/www || exit
unset GIT_DIR
git pull hub master

exec git update-server-info

Post-commit — в Prime-репозитори

echo
echo «**** pushing changes to Hub [Prime’s post-commit hook]»
echo

Итак, используя этот хук, мы сразу же получаем в Hub-репозитория все изменения, выполненные в master-ветке Prime-резпозитория. Прочие ветки также можно клонировать, но они не будут влиять на сайт. Поскольку все удалённые копии получают доступ через SSH-адрес к Hub, то выполнить push и запустить обновление сайта напрямую могут только пользователи, имеющие прямой доступ к shell’у.

Конфликты

«Положить» сайт при такой системе синхронизации двух репозиториев очень сложно. Каждое изменение, сделанное в Prime автоматически попадает в Hub и все конфликты будут сразу видны при попытке выполнить push из клонов репозитория.

Но всё же есть несколько ситуаций, при которых состояние Prime может отличаться от Hub’а, и для исправления ситуации потребуется выполнить несколько дополнительных телодвижений. Если мы что-то правим на Prime и не зафиксировали изменения, а в этот момент сработает post-update в Hub, то все завершится ошибкой с сообщением «Entry ‘foo’ not uptodate. Cannot merge.». Фиксация изменений в рабочем каталоге Prime позволит зачистить его состояние, и post-update хук сможет соединить все неотправленные изменения.

Также я обнаружил, что если конфликт возникает вследствие того, что изменения в Prime не могут быть объединены с Hub’ом, то наилучшим решением будет протолкнуть текущее состояние Prime’а в новую ветку на Hub. Эта команда, выполненная из рабочего каталога Prime создаст удалённую ветку «fixme», основанную на текущем стоянии Prime-репозитория.

$ git push hub master:refs/heads/fixme

Как только изменения окажутся в Hub’е, мы сможем получить ветку в любом из клонов, разрешить конфликт и смержить ветки. Попытка разрешить конфликт прямо на сервере почти наверняка приведёт к проблемам в работе сайте из-за появления маркеров конфликтных областей.

Держим всё в чистоте

# deny access to the top-level git repository:
RewriteEngine On
RewriteRule \.git — [F,L]

Прим. переводчика: есть и другие способы закрыть доступ к каталогу на сервере.

Прочие проблемы

git-receive-pack: command not found
fatal: The remote end hung up unexpectedly

/bin в ваш файл .bashrc, лежащий на сервере.

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Ежедневная работа с Git

Постигаем Git

Git Workflow

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 49

Именно так работает сайт erlyvideo.ru/ (он же и erlyvideo.org/)

Из одной папки в гите берутся файлы, выбирается русский или английский вариант и смотрим.

Я как раз на прошлой сделал что-то похожее на Mercurial.

Смысл такой: к существующей системе контроля версий добавился репозиторий на тестовом сервере, в котором стоит хук на пуш. Поэтому для обновления версии достаточно выбрать удалённый репозиторий и ввести логин-пароль (отличающийся от пароля в рабочем репозитории, чтобы избежать случайного пуша куда не надо).

* * * * * cd /home/project/project/ && /usr/bin/hg -q pull && /usr/bin/hg update production | grep -v «0 files updated, 0 files merged, 0 files removed, 0 files unresolved» && /bin/touch web/django.wsgi

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

Не делал хуков на push (или всякие fabric’и) именно по причине требования к нулевому общему даунтайму.

Ну а само обновление продакшн-нод досигается просто перемещением метки production на нужную ревизию.

Зачем?! Зачем использовать систему контроля версия для деплоя?!

Нет, я, конечно, прочитал, что в статье есть предложение по закрытию доступа к .git директории, но что, если админ ошибется и не сможет правильно настроить mod_rewrite (или правила nginx)?

Почему для деплоя не пользоваться утилитами, специально для этого предназначенными? К примеру, тот же Capistrano (а еще лучше capistrano-ext со стейджингом, чтобы случайно не деплойнуть на продакшн неподготовленный код).

Ну… с гитом подобной проблемы, как у svn, нет. Достаточно только, чтобы DocumentRoot хоста находился внутри каталога проекта, или вообще в отдельном каталоге.

Все свои потроха гит содержит аккуратно, не разбрасывая их по подпапкам проекта.

А в статье где-нибудь указано, что данный подход желательно применять только на небольших проектах?

И еще, настройка репозиториев, хуков, mod_rewrite, а также системы сообщения между prime и hub репозиториями затмит собой настройку скрипта для capistrano и пробросу пары ключей между машинами 🙂

Откатите продакшен на 1 версию назад находясь на рабочей машине. Через git деплоить хорошо, да, но не так как это сделал автор, зачем второй репозиторий? Делать экспорт прямо из bare в нужный каталог.

> пользователей капистраны немного жалко.

Вы просто не умеете ее готовить. Тоже самое говорят хомячки про пользователей unix like os и эникейщики про сервера на unix like.

> Тоже самое говорят хомячки про пользователей unix like os и эникейщики про сервера на unix like
я работаю на Ubuntu 11.04, продакшн-сервера все на Ubuntu. и капистрано тем не менее для меня монструозен.

выше я написал, что в отличие от автора у меня один реп, да.

Вы кажется не поняли метафору…

> выше я написал, что в отличие от автора у меня один реп, да.

git archive master | tar -x -C /somewhere/else

git-archive —format=tar —remote=ssh://remote_server/remote_repository master | tar -xf — в пост-апдейт хук и все.

> deploy.sh:
git checkout master
git merge newfeature
git merge bugfix
git push server master

git алисы вы не осилили, ога.

зачем мне алиасы там, где я не ввожу команды руками?

ваш вариант с гит-архивом я вообще понять не могу. зачем мне делать на сервере отдельно папку с репом (в который всё равно для деплоя надо будет пушить), и отдельно папку, в которую будет разархивироваться деплой? и что мне делать, если у меня в свежем деплое найдётся критикал баг, и надо будет срочно откатиться назад? иметь в продакшене рабочий реп тоже полезно.

метафору я понял. только вот не понял, зачем вы её здесь привели. удобство капистраны настолько субъективная вещь, что сравнивать её с *nix системами — как сравнивать тех, кто не любит анчоусы с теми, кто не ест жирное.

как разрешаются конфликты при git pull?

этой проблемы не возникает, если с девелоперского сайта делать git push на продакшн.

txtrst=’\e[0m’ # Text Reset
txtred=’\e[0;31m’ # Red
txtgrn=’\e[0;32m’ # Green
WORK_TREE=’/some/path/on/dev/server/’

while read oldrev newrev ref
do
case $ref in
refs/heads/dev )
echo «========================================»
git —work-tree=$WORK_TREE checkout -f dev
if [ $? -eq 0 ]; then
echo -e «$DEVELOPER SERVER successfully updated$»
else
echo -e «$Failed to checkout DEVELOPER SERVER!$»
fi
;;
refs/heads/master )
echo «========================================»
git push gsl master:master
if [ $? -eq 0 ]; then
echo -e «$PRODUCTION SERVER successfully updated$»
else
echo -e «$Failed to push to PRODUCTION SERVER!$»
fi
;;
* )
echo «NO UPDATES FOR $1»
;;
esac
done
echo «========================================»

вот мой post-receive hook на девелоперском сервере.
принцип работы: есть две ветки — master и dev. изменения в ветке dev checkout’ятся в DOCUMENT_ROOT девелопеского сервера. А изменения в ветке master push’атся в bare-репозиторий на продакшн-сервере, а оттуда уже аналогичным образом chekout’ятся в его DOCUMENT_ROOT

Пытаюсь найти еще информацию по теме выкладывания новой версии на продакшен, но не могу найти.

Подскажите ключевые слова 🙂

У нас за доли секунды несколько сотен запросов на сервера приходит…
Во время деплоя ничего отрубать нельзя.

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

В общем, мы сейчас о немного разных вещах говорим… Наверное, нужно было просто разобраться немного в джите и не задавать того вопроса 🙂

Наша deploy-система блокирует проект, обновляет файлы, структуру базы, настройки cron, перезапускает отдельные сервисы, etc. а потом снимает блокировку. Это гарантирует, что в процессе обновления не получится так, что часть файлов/базы уже обновилась, часть ещё нет, и тут приходит запрос пользователя и он обрабатывается смесью старого и нового кода с в принципе непредсказуемыми последствиями. Кроме того, это гарантирует, что если обновление затянется или сломается в процессе, то пользователь получит статическую страничку «server maintenance, please try again later».

Системы контроля версий всё это делать не умеют и они вообще не предназначены для реализации deploy. Можно, конечно, навесить на них сложные системы хуков и получить почти то, что требуется, но это сложно и не правильно. Для deploy нужно использовать предназначенные для этого системы. И выкатывать новую версию на production сервер нужно ручками, а не автоматически (не в том смысле, что файлы/базу ручками обновлять, а в том смысле, что во-первых желательно перед обновлением глазками просмотреть все изменения — т.е. patch/sql/etc.-файлы — и во-вторых присутствовать при установке этих изменений на сервере на случай если что-то пойдёт не так).

Единственная сложность такого надёжного подхода в том, что все приложения проекта (cgi-шки, fastcgi-сервер, сервисы, cron-скрипты, qmail-скрипты, консольные утилиты) должны поддерживать единую систему блокировок, чтобы было возможно их всех одним махом заблокировать на время обновления системы (все приложения ставят shared-lock в процессе работы, а при обновлении ставится exclusive-lock). Но при наличии таких блокировок решается не только проблема атомарного обновления проекта, но и консистентного бэкапа.

источник

Добавить комментарий

Adblock
detector