Среда разработки с несколькими разработчиками в одном приложении

Я ищу хороший способ оптимизировать/улучшить способ работы моих коллег и наших приложений.

В настоящее время мы работаем в PhpStorm на MacBook Pro (2016), сервере Ubuntu в нашей сети и рабочей копии, сопоставленной с общим ресурсом SMB на наших компьютерах (мы иногда редактируем одни и те же файлы, что делает это неудобно). Мы используем Git как источник управления и имеем 1 ветвь, в которой все мы работаем.

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

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

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

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

TL; DR, что является хорошим способом работы с одним приложением с 3 разработчиками.

Ответ 1

https://www.atlassian.com/git/tutorials/comparing-workflows

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

Как только вы получите эту идею, тогда, как мне кажется, все остальное.

Всегда обновляйте локальную ветку от мастера и теста перед проверкой
Заходите часто! Несколько раз в день. См. Пункт 1. Каждая проверка должна содержать как соответствующий код, так и код SQL script (и любые другие ресурсы), и должна компилироваться и работать!
Сливаются конфликты. Нет волшебной палочки или стратегии. В общем, попробуйте координировать работу так, чтобы разработчики обычно работали над изолированными областями (это предполагает, что ваш код хорошо структурирован для этого. Это, как правило, хорошая идея, но слишком большая тема для этого). Я рекомендую хранить изменения в файле с любым кодом, который автоматически генерируется одному разработчику за раз. (это опыт!).
Все изменения в базе данных должны быть script и, следовательно, файл кода, обрабатываемый точно так же, как и весь другой код с точки зрения контроля версий, разработчики должны тестировать свою собственную локальную копию базы данных до ее совершения. Вероятно, вам нужен кто-то, кто будет контролировать сценарии до выпуска, искать конфликты. У вас может быть правило, что есть один файл script для каждого объекта базы данных (таблица, представление, sp), упрощает его!

Ответ 2

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

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

Возможно, вы посмотрите, как это применяют другие. Существуют фреймворки, которые поддерживают это из коробки (например Laravel для PHP).

Ответ 3

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

Чтобы свести к минимуму конфликты слияния, я предлагаю создать ветвь dev, и для каждой функции она должна отделяться от ветки dev и быть изолированной до тех пор, пока не будет либо обновление (кто-то слился, либо вы закончите с функцией и объединили). Другие разработчики могут затем извлечь эти изменения из dev и продолжить их функцию.

Если проблема основана на среде, вы можете использовать функцию докера в JetBrains ides для создания общей среды для работы.

Ответ 4

После добавления комментария к исходному ответу, я думаю, что это должно быть предоставлено в качестве ответа:

Используйте git как инструмент управления версиями. Благодаря тому, что все разработчики работают на одном ресурсе, вы определенно не используете преимущества управления версиями. Попросите каждого разработчика работать на собственных рабочих деревьях (локально или на сервере, если вы хотите сохранить его таким образом), чтобы они могли использовать функции git для локальной разработки (создавать собственные ветки, быстро выполнять операции, не испортить что делают другие люди), а затем объединить вещи в верхних ветвях развития, когда все будет готово. Это должно позаботиться о многих ваших проблемах.

Этот главный приоритет в моем списке.

Ответ 5

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

Ответ 6

Вы должны хранить репозитории GIT в централизованном месте, например. в Github или на одном из ваших локальных серверов. Любой разработчик может вытащить/сдвинуть изменения из/в центральный репозиторий и работать с локальной копией (без SMB-сетей).

Рассмотрим использование контейнеров Docker. Это позволит обеспечить вам все одинаковые среды разработки.

Изменения базы данных могут быть выполнены с использованием миграции базы данных. См. Эту библиотеку doctrine/migrations.