Как управлять проектом Google App Engine в команде? - PullRequest
4 голосов
/ 14 августа 2010

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

Любые предложения по управлению проектом Google App Engine вкоманда?

1 Ответ

7 голосов
/ 14 августа 2010

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

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

Я бы порекомендовал, как минимум:

  1. Получите хороший VCS и убедитесь, что разработчики знают, как его эффективно использовать
  2. Разработчики должны разрабатывать и тестировать локально, используя dev_appserver.py из SDK. Учитывая удаленный API, sqlite backend и т. Д., Нет причин, по которым это невозможно. Если вам нужны живые данные, создайте что-то репрезентативное, что вы можете использовать локально. Даже поведение, которое радикально отличается в SDK и в реальном времени (например, параллелизм), вряд ли когда-либо будет проблемой во время разработки.
  3. Пусть разработчики передадут репозиторий, и пусть какой-то конкретный человек (в идеале, с помощью сценариев для предотвращения человеческих ошибок) будет отвечать за развертывание новой версии приложения, отличной от версии по умолчанию
  4. Хорошо протестируйте новое развертывание, прежде чем сделать его новой версией по умолчанию для ваших пользователей
...