Блог

Итак, я искал на этом сайте, я прочитал руководство по gitimmersion.com и многие другие, но у меня все еще есть нерешенные вопросы, на которые, я надеюсь, кто-нибудь сможет ответить.

В принципе, у меня есть веб-сервер, на этом сервере у меня есть два домена, dev.domain.com и основной сайт www.domain.com.

Прямо сейчас «производственный» домен является заполнителем страницы «Скоро», и dev.domain.com это реально работающий сайт. В конечном итоге git может / будет использоваться для обработки переходов от разработчика к производству, но на данный момент сайт все еще находится в стадии разработки.

Недавно, из-за того, что в проект пришли несколько других людей, я решил использовать контроль версий, в частности git. Я настроил webroot моего домена разработчиков в качестве репозитория и отправил его в codebasehq.

Вот тут я и запутался.

Я выяснил, как извлекать код, извлекать его, нажимать на него, делать коммиты и т.д. Чего я не понял, так это правильного способа фактического тестирования разработки. Позвольте мне дополнить это предыдущее утверждение примером:

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

Как мне это сделать сейчас?

Можем ли мы все иметь учетные записи на box и находиться внутри webroot dev.domain.com сайт и редактирование / тестовые правки? Нужен ли каждому из нас собственный маленький сервер LAMP для тестирования на наших рабочих станциях?

Я действительно запутался в правильном способе справиться с этим. Если я проверю код на своем локальном компьютере, я смогу редактировать файлы по своему усмотрению, но в итоге мне придется сделать 400 коммитов / нажатий только для проверки вещей и вносить исправления каждый раз, когда я забываю точку с запятой, поскольку у меня нет способа протестировать это локально.

Я что-то упускаю или ответ такой простой, как «Уверен, что вы все можете редактировать в webroot, и он будет отслеживать изменения для каждого пользователя» или «Нет, вам всем нужен свой собственный способ тестирования вашего кода, прежде чем вы его опубликуете»

Раньше я никогда ничего не разрабатывал совместно, поэтому привык просто редактировать / тестировать на лету, поэтому, пожалуйста, простите мое невежество.

В качестве резюме, вот чего я пытаюсь достичь:

Команда из трех человек разрабатывает веб-сайт; dev.domain.com это область «тестирование / разработка» на моем веб-сервере. В какой-то момент, www.domain.com станет отправной точкой для производства. Все члены команды разработчиков имеют доступ по ssh и учетные записи на сервере.

Как мне связать все это с git, учитывая, что локальная среда тестирования на моем домашнем компьютере не идеальна (но выполнима), и что я уже создал учетную запись на codebasehq.com в качестве основного репозитория git, который был создан из webroot dev.domain.com.

Заранее спасибо!

Это то, что я делаю (разумные люди могут не согласиться):

1) Протестируйте локально, используя стек LAMP на моей рабочей станции, при этом по ходу работы переходя на git.

2) Когда я буду готов реинкорпорировать свой локальный филиал, я нажимаю на origin. Репозиторий находится на моем производственном сервере.

3) Когда мы хотим выполнить тест развертывания, он выполняется на поддомене тестирования на рабочем сервере, скажем test.foo.com.

Вот тут-то и возникает сложность: предположим, корневой каталог документа для производственного сайта ‘foo.com/httpdocs ‘. Это символическая ссылка на один из foo.com/httpdocs1 или foo.com/httpdocs2. Корневой каталог документа поддомена также является символической ссылкой на другой каталог, поэтому, если для производства задано значение httpdocs1, для тестирования — httpdocs2.

Мы выполняем развертывание в каталоге тестирования, затем, когда мы удовлетворены тем, что все на месте (предполагая, что мы хотим обновить производственный сайт), мы переназначаем производственную символическую ссылку и в другой каталог. Таким образом, переключение происходит в рамках одной операции с файловой системой atomic, если вы используете perl rename или что-то подобное для изменения символьной ссылки (вместо того, чтобы отсоединять и перелинковывать).

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

Вы должны тестировать локально и вводить только тот код, который работает.