управление зависимостями — крупный PHP-проект: лучшие практики по ограничению доступа к файлам только теми файлами, которые нужны разработчику
Мы создали большой пользовательский PHP-проект, построенный на нашей собственной среде MVC. Структура очень хорошо структурирована с файлами, хорошо организованными и разбитыми на определенные страницы / методы / классы.
Мой основной кодер и я работаем над кодом постоянно, и у нас есть полный доступ. Я могу доверять своему главному программисту, но теперь мне нужно нанять дополнительную помощь. Я нашел несколько отличных кодеров, но я беспокоюсь о том, чтобы разрешить им FTP-доступ к нашей системе, чтобы начать работу, и я не осмелюсь разрешить им доступ ко всем файлам!
Мой главный вопрос: как разрешить разработчику доступ только к определенным файлам, в которые он должен внести изменения?
Я рассмотрел возможность шифрования всего проекта с помощью ionCube или чего-то подобного, а затем только дешифрование определенных файлов, но это громоздкое решение. Другая идея состоит в том, чтобы добавить операторы PHP include () внутри основного кода в файлы, над которыми он будет работать, ограничивая их одной папкой и предоставляя ему доступ к этому. Это также громоздко, потому что проблема может быть связана с областью ключевых слов и т. Д. Кроме того, кодирование разработчика в его собственных файлах является лишь частичным исправлением, поскольку ему нужно будет просмотреть содержимое нескольких других связанных файлов для методов / функций / классов. Было бы неплохо просто выбрать список файлов, к которым у разработчика есть доступ, и не разрешать ему просматривать другие файлы. Это позволит мне открыть достаточно маленькое окно для разработчика, чтобы он мог свободно кодировать без необходимости микроуправления им (или помещением кода, написанного разработчиком, в основные файлы).
Это действительно сводится к защите кодовой базы. У меня нет опыта корпоративного развития, поэтому я не уверен, как «большие парни» делают это. Любые предложения / указания мне в правильном направлении были бы серьезной помощью!
Решение
Так что, видимо, ваш проект не очень хорошо структурирован. В противном случае вы могли бы разделить его на отдельные репозитории, где каждый из них находится «вне контекста», поэтому доступ к нему будет бесполезен с точки зрения «кражи бизнес-логики», но достаточным для некоторой разработки…
Попробуйте разделить его на отдельные части как пакеты, а затем поместить их в свой vendor каталог, в котором каждый пакет имеет свой git репозиторий.
Затем (как вы уже догадались) вы предоставляете доступ только к определенному репо, не беспокоясь о том, что весь ваш «код» будет украден.
Но помимо этого вы должны начать с доверия людям, которых вы нанимаете!
Другие решения
Во-первых, это не такой плохой вопрос, как предполагают отрицательные голоса. Если речь идет о действующей системе, предположим, что компания страдает от нарушения данных, и это происходит потому, что разработчик стал мошенником, просмотрел учетные данные базы данных из файла конфигурации и затем злоупотребил этими знаниями; работник, очевидно, виновен, но компания также будет халатна и может быть привлечена к ответственности, потому что зашифровывая или другими способами они мог предприняли шаги, чтобы предотвратить доступ к учетным данным в первую очередь, но они не беспокоили. Это будет неспособность компании приложить все усилия для защиты учетных данных базы данных, которые включен нарушение безопасности.
В крупных организациях может быть команда контроля изменений, отвечающая за развертывание изменений, так что ни один разработчик никогда не будет иметь доступа к действующей системе. Нечто подобное можно сделать, когда разработчики вносят изменения в код, а третья сторона проверяет изменения перед развертыванием в действующей системе. Это не микроуправление, а обеспечение того, чтобы дополнительная пара глаз могла рассмотреть, что было сделано, каковы могут быть последствия, и дает возможность обнаружить непреднамеренные ошибки. Рецензент не эмоционально инвестирует в просмотр развернутых изменений, но обеспокоен тем, что они собираются сделать в системе, есть ли изменения в базе данных, когда лучшее время для развертывания, на кого это повлияет, как они могут откатиться, если необходимо, кого нужно информировать об изменениях и т. д. Разработчик, вероятно, не рассмотрит ни одну из этих вещей. Использование контроля версий в действующей системе в качестве способа простого отката, а также записи происходящего также очень эффективно.
Если вы хотите, чтобы группа разработчиков не видела некоторый код во время разработки, кодирование, безусловно, является одной из возможностей, и это может потребоваться по юридическим причинам, а не только по личным причинам. Это может быть достигнуто с помощью различных репозиториев для каждого набора кода, который должен быть ограничен, и инструмента, который разработчики могут использовать для получения защищенных версий кода в той или иной редакции. Связанный подход может состоять в том, чтобы поддерживать теневые репозитории с закодированными версиями файлов. Это может быть обновлено с использованием перехватов после фиксации в исходных репозиториях и предоставления разработчикам доступа только к закодированным репозиториям для ссылки в их внешней конфигурации (для использования языка SVN).