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

Question

Моя команда работала над веб-приложением на основе php, msql для backend и html, css, jquery для front end. Мы работаем довольно долго без контроля версий. Проект стал довольно большим и сложным, и теперь пришло время использовать какой-то контроль версий (vc).

Мы много читали о vc и нашли несколько техник, которые предложили люди. хотя это может быть идеальным методом для них. это не относится к нашему делу.

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

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

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

Есть ли способ решения вышеуказанной задачи? для веб-приложения? использовать контроль версий, как Subversion?

Подводя итог, мы пытаемся реализовать следующие функции:

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

2. Ограниченный доступ (Каждый разработчик может получить доступ только к определенной части проекта, а не ко всему проекту.)

3. Онлайн-хранилище / Онлайн-копия - (мы работаем над подключением VPN и хотели бы, чтобы веб-сайт работал с онлайн-копией. Поэтому, когда выполняется фиксация, разработчик может просматривать свои изменения онлайн вместо VPN)

---

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

1. Для мгновенных эффектов -> Вся система извлекается из папки webroot (например, wamp / www / projectName), файл bat вызывается для обновления текущей системы в webroot каждый раз, когда выполняется фиксация. с помощью хука post-commit.
2. Ограниченный доступ -> Вся разработка для всех разработчиков происходит в транке ИЛИ в ветке разработки, разработчики могут получить доступ к своим соответствующим разделам, заблокировать их при необходимости и зафиксировать изменения, когда они будут готовы увидеть его эффекты (обратите внимание, что в ветке dev).
3. создаются всякий раз, когда создается стабильная версия. эти помеченные копии никогда не изменяются.

Достижима ли такая конфигурация с помощью Subversion или мы должны взглянуть на другие инструменты контроля версий с открытым исходным кодом?

Answer 1

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

В любом случае ..

Самый простой способ достичь желаемого - это поместить каждый модуль в свой собственный репозиторий (svn, git и т. Д.). Затем вы можете выборочно выбирать, кто имеет доступ к какому репо.

Answer 2

Во-первых, я бы рекомендовал прочитать книгу «Непрерывная доставка» (веб-сайт здесь ). В нем много примеров того, как настроить подобные вещи.

Во-вторых, да, SVN позволяет назначать разрешения на уровне папки , а также на уровне репо (но прочтите раздел «Вы действительно хотите это сделать»).

В-третьих, следуя дисциплине, убедитесь, что разработчики имеют последние копии, - «перед началом работы и перед фиксацией запустите svn update»). Хуки после коммита имеют неприятную привычку ломать вещи, и вы не предотвращаете коммиты, которые ломают сборку.

В-четвертых, я бы подумал о настройке сервера непрерывной интеграции (также описанного в книге «Непрерывная доставка»). Это гарантирует, что у вас будет чистая, работающая сборка всякий раз, когда вы собираете работу ваших разработчиков.

Answer 3

1. Хук после фиксации, который безусловно"делает сайт" является общей не очень хорошей идеей : разработчик может зафиксировать полуфабрикат и даже не работатьНе думайте о его тестировании
2. Сделайте свою рабочую копию общедоступной, когда сайт станет общедоступным - не очень хорошая идея с точки зрения безопасности и IP.Для SVN 1.7 гораздо удобнее перемещать WC-корень за пределы web-корня
3. Если модули разделены на разные каталоги, вы можете создать репозиторий для каждого модуля и «супер-репозиторий», который с помощью svn: externalsобъединить репозитории в Project
4. Доступ к пути внутри дерева можно легко контролировать (в http-repo) с помощью authz_svn_module
5. Включить создание личных личных кратковременных ветокдля разработчиков ("полки") помогает избежать (с 1) огромных испорченных коммитов