Назад | Перейти на главную страницу

Как настроить нескольких пользователей на сервере разработки с помощью git и github

Я работаю над применением лампы. У нас есть 2 сервера (Debian) Live и Dev.

Я постоянно работаю над dev main, чтобы добавлять новые функции и исправлять ошибки.
Когда все работает хорошо, я загружаю соответствующий код в систему Live. База данных (mysql) является локальной для каждой машины.

На самом деле это довольно простая настройка, и я хочу немного улучшить рабочий процесс. Я использую git и github для контроля версий. По общему признанию, я действительно использовал только одну ветку. Это могут быть 3 разных разработчика, которые работают над кодом в разное время. Мы все используем одно и то же имя пользователя linux для подключения к серверу разработки и редактирования кода напрямую, когда это необходимо. Я обычно затем фиксирую и отправляю код в конце дня на github.

Следует иметь в виду, что запустить этот код на локальном компьютере непросто, поскольку существует множество конфигураций apache и поддоменов, которые не работают на локальном компьютере, поэтому важно работать на сервере разработки не локально.

Мне нужно создать новый процесс, потому что теперь у нас должен быть основной ствол и ветка с большим переписанным кодом.

Как лучше всего это сделать. Должен ли я создавать разные логины unix для каждого разработчика и настраивать разные рабочие области на сервере разработки для внесения изменений? например

/ var / www / mysite_derek / var / www / mysite_paul / var / www / mysite_mike

Я думаю, что они могут извлечь из основной ветки, а затем создать там собственную ветку и снова объединить ее. Я не уверен, как это будет работать, хотя с git локально и с github.

мне нужно будет также создать разные учетные записи пользователей github.

Я бы хотел сделать это «правильным» способом и будущим доказательством наличия большого количества потенциальных разработчиков, но я также не хочу чрезмерно усложнять это. Я предпочитаю простое и элегантное решение.

какие-нибудь рекомендации или предложения?

Решение, которое мы используем примерно с 12 разработчиками, заключается в следующем. Он работает очень хорошо и обеспечивает гибкую настройку без необходимости больше изменять конфигурацию сервера. Вероятно, он не будет масштабироваться до 40-50 разработчиков из-за задержки в сети и скорости серверного хранилища.

Мы разделяем / var / www / дерево через Samba, поэтому клиенты Windows могут использовать свои локальные IDE и VCS-клиенты для редактирования на сервере LAMP. Ни у кого нет учетной записи на сервере Linux.

Создайте структуру каталогов следующим образом:

/var/www/mysite.com/www/derek/
/var/www/mysite.com/www/paul/
/var/www/mysite.com/www/mike/

Во внутреннем DNS создайте запись с подстановочными знаками, которая указывает **. Dev * на IP-адрес вашего сервера лампы. Я предполагаю, что 123,45,67,89 Вот.

В Apache определите виртуальный хост, который выглядит примерно так:

<VirtualHost 123.45.67.89>
   ServerName lamp.dev
   ServerAlias *.dev
   VirtualDocumentRoot /var/www/%-3.0.%-2/%-4/%1/
</VirtualHost>

Важными частями являются подстановочный знак ServerAlias, который заставляет этот виртуальный хост отвечать на все входящие запросы, заканчивающиеся на .dev. Другой важный - VirtualDocumentRoot, который выглядит сложным, но не так уж и плохо. Он просто разрезает входящее имя хоста на части и создает DocumentRoot из частей. Ты можешь Об этом подробнее здесь.

Теперь любой разработчик может посетить http://derek.www.mysite.com.dev/ и просмотреть их личную рабочую копию mysite.

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

Для развертывания на производственных серверах я бы порекомендовал вам отказаться от scp и посмотреть Capistrano, и отличный централизованный веб-интерфейс Webistrano. Capistrano немного ориентирован на Rails, но, например, для адаптации к PHP требуется всего несколько строк. Webistrano предоставляет центральный графический интерфейс, в котором вы можете развернуть или обновить сайт прямо из системы управления версиями одним нажатием кнопки. Нельзя игнорировать развертывания, легко создаваемые сценариями, которые можно надежно повторять и откатывать в случае возникновения проблем.