Агентство веб-дизайна, использующее Git для разработки - PullRequest
0 голосов
/ 27 сентября 2011

Фон

До сих пор мы использовали Plastic SCM для контроля версий.Недавно мы изучали Git, и я разработал базовый план - Доступен здесь, в Документах Google

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

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

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

Вопросы

  1. Видите ли вы какие-либо дыры в этом плане?
  2. Правильно ли использовать Git для такого рода структур?
  3. Существует ли уже существующий план, который мы могли бы использовать вместо этого?

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

Ответы [ 2 ]

2 голосов
/ 27 сентября 2011

Посмотрите, как работают Heroku и AppHarbour.Вы определенно на правильном пути.

0 голосов
/ 05 декабря 2012

Вам следует рассмотреть возможность использования Gerrit - механизма проверки кода, который также является полностью git-совместимым git-сервером.Gerrit написан на Java для нужд проекта Google для Android.

Вы можете использовать функциональность обзора, чтобы контент «запекался» в очереди на утверждение, пока он не был окончательно одобрен и не стал официальным (или снова отклоненным / проверенным).В то же время вы можете установить гибкие правила доступа для разных людей - например, кто-то может принудительно пропустить проверку кода (в этом случае он становится просто стандартным git-сервером), или может только отправлять на проверку, или одобрять, или только голосоватьили вниз - вы устанавливаете правила.Если у вас есть несколько git-репозиториев, вы также можете ограничить доступ к некоторым очень секретным репозиториям от пользователей, которым вы не доверяете, или от третьих лиц.

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

...