разработка с использованием git и php (веб-разработка)

Question

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

• Создайте копию действующего рабочего каталога и клонируйте этот каталог 'dev' на локальную рабочую станцию. Следующим шагом будет редактирование кода на локальной рабочей станции и принятие / отправка каждого изменения. Вы можете проверить свою работу через URL-адрес «dev» на производственном сервере. Если все в порядке, вы можете отправить изменения в «живой» каталог. Этот подход может привести к большому количеству коммитов, так как вы редактируете / исправляете свой код (синтаксические ошибки или другие очевидные ошибки), и он добавляет дополнительный шаг (фиксация / push), чтобы увидеть ваш результат.

• Создайте сервер 'dev', который отражает рабочий сервер. Этот сервер будет содержать все файлы инфраструктуры, и вы сможете напрямую редактировать копию «живого» каталога и сразу же видеть ваши изменения. Если вы предпочитаете, вы можете смонтировать удаленный каталог 'dev' на вашей локальной рабочей станции. Для этого требуется дополнительный сервер, который необходимо обслуживать, и вам потребуются ресурсы для его настройки.

• Создайте локальную среду рабочей станции 'dev' и клонируйте репозиторий на 'live' или 'dev' сервере. Таким образом, вы сможете протестировать весь код на своем локальном компьютере и выдавать только те коммиты, которые были протестированы и одобрены. Это уменьшает количество коммитов в отличие от первого метода. Чтобы локально воссоздать среду 'dev', вам может потребоваться установить множество инфраструктурных / зависимых файлов на вашу локальную рабочую станцию, и даже тогда это может быть не надежно на 100%, когда код переносится на реальный работающий сервер.

По сути, я хочу найти лучший метод для 'write-test-revise-test-revise-test-commit' цикл, если вы зависите от файлов фреймворка (какой бы фреймворк это ни был). Вы бы создали сервер 'dev' или воссоздали бы точную производственную среду на своей локальной рабочей станции? В идеале вы должны фиксировать код только после первоначального тестирования (очевидные синтаксические ошибки и т. Д.). Сервер 'dev' с локальным git-репо потребовал бы, чтобы вы вносили каждое небольшое изменение, чтобы проверить свою работу, которая может быть утомительной ....

Надеюсь, я ясно дал понять. Я ищу лучший способ интегрировать git и цикл 'write-test-commit'. Обычно вы тестируете на локальном компьютере, но при веб-разработке вам может понадобиться веб-сервер + фреймворк, чтобы иметь возможность тестировать ваш код. Редактирование непосредственно на «живом» сервере - вот чего я хочу избежать.

Спасибо за ваш вклад!

Answer 1

Определенно есть много способов сделать это, но вот мои 2 цента от того, как я работал в последнее время.

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

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

В моей среде я занимаюсь разработкой под Linux и использую Apache / PHP с теми же версиями и конфигурациями, что и на живом сервере. Таким образом, я клонирую мое git-репо, настроив свою среду так, чтобы мой корневой каталог документов был «публичным» каталогом моего git-репо (например, htdocs). В этом случае у нас есть dev-сервер MySQL, который обычно используется совместно, а не на локальной машине, но вы можете делать все, что проще. Наша система зависит от постоянно обновляемых данных с месторождений, поэтому в общей базе данных у нас есть система, которая автоматически добавляет много необходимых «тестовых» данных в базу данных.

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

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

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

Я бы отказался от ваших методов 1 и 2 и пошел бы с чем-то вроде 3. Это, вероятно, будет самым разумным для вас делом и простым в управлении. В зависимости от того, на что похожа ваша команда, вы можете создать предустановленную виртуальную машину со всеми зависимостями, правильным программным обеспечением и инструментами разработки, которые вы все используете, или оставить на усмотрение разработчика настройку.

Пока что этот метод очень хорошо работал для меня и других в моей команде.

Answer 2

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

Когда вы окажетесь там, должно быть тривиально, чтобы каждый разработчик настроил виртуальную машину с чистой установкой ОС, настроил серверы web / php / db и библиотеки / framewroks для соответствия производственной среде, проверил ваш проект, и приступай к работе.

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

Точные правила о том, как объединить изменения в мастер, зависят от предпочтений вашей команды. Но у разработчиков почти всегда должна быть полная локальная среда разработки. Если кажется, что его сложно установить, это большая проблема. Выясните, как сделать это проще, а затем задокументируйте это.