Есть Mercurial репозиторий с программным решением, который используется внутри компании ограниченным кругом разработчиков.
В данном репозитории есть конфигурационные файлы с подключением к БД.
В данный момент планируем привлеч к разработке удалённого сотрудника. Но есть необходимость ограничить его доступ к основной БД.
Решили запустить новый инстанс с БД, куда будут реплицироваться данные с основной БД.
К данной БД дать доступ удалённому разработчику для его экспериментов.
Хотим скрыть данные о подключении к основной БД, но они есть в истории.
Ищу решение этой проблемы. Как вариант теоретически это может быть ещё одна версия репозитория, с которой можно будет каким-то образом мержить основную версию.
Прошу посоветовать решение для этой проблемы.
Re: Mecrurial: Ограниченная версия репозитория для нового удалённого сотрудника.
Здравствуйте, WSA, Вы писали:
WSA>Есть Mercurial репозиторий с программным решением, который используется внутри компании ограниченным кругом разработчиков. WSA>В данном репозитории есть конфигурационные файлы с подключением к БД.
Надежнее всего не хранить конфиги с реальными параметрами БД, а хранить их где-то отдельно (на стендах или в другом закрытом репозитории, если нужна историчность).
Если можно обойтись локальной базой, можно для разработки хранить в репозитории параметры соединения с такой локальной БД, унифицированной по всем разработчикам (типа server=localhost;db=project_dev;user=localdev;password=localdev). На тест- и препрод- стендах — свои конфиги со своими базами.
Если нужна какая-то централизованная, но разная для разных разработчиков или реальная, которую нельзя светить, — то конфиг с соединением с БД не хранится, хранится его пример, а разработчик уже себе его настраивает под себя. Такой файл должен быть игнорируемым в hg, чтобы случайно не был сложен с реальными параметрами, что может быть не очень удобно, если в конфиге и база и другие параметры, которые меняются. В .net может помочь встроенная поддержка иерархии конфигов, т.е.
* appsettings.json — базовые настройки, тут реальной строки соединения нет.
* appsettings.dev.json — игнорируемый в hg, персональные настройки разработчика в т.ч. важные строки соединения и т.д., переписывающие базовые настройки.
WSA>Хотим скрыть данные о подключении к основной БД, но они есть в истории.
Тут боюсь только поменять учетку в БД. Отдельные коммиты можно удалить из истории, но коммиты, а не их части, да и для старой истории, которая уже расползалась по разным местам это та еще головная боль, не советую.
Re[2]: Mecrurial: Ограниченная версия репозитория для нового удалённого сотрудни
Спасибо за подрообный ответ.
F>Тут боюсь только поменять учетку в БД. Отдельные коммиты можно удалить из истории, но коммиты, а не их части, да и для старой истории, которая уже расползалась по разным местам это та еще головная боль, не советую.
А можно ли сделать эквивалентную копию репозитария, как бы с нуля, скопировав туда содержимое последней версии репозитория и мержить этот новый репозиторий с основным....
Ещё изучаю вариант ограничения пользователя репозитория, но кажется allow_read permission действует на весь репозиторий, былобы неплохо ограничить чтение default-ветки, а удалённому сотруднику открыть параллельную ветку и разрешить работать только с ней. Мержить с default-веткой без привлечения удалённого разработчика.
Re: Mecrurial: Ограниченная версия репозитория для нового удалённого сотрудника.
Здравствуйте, WSA, Вы писали:
WSA>Прошу посоветовать решение для этой проблемы.
На что только люди не готовы пойти чтоб только не убирать пароли из репозитория с исходниками?
Положите пароли и прочие секреты в другое место, очевидное же решение.
WBR, Igor Evgrafov
Re[2]: Mecrurial: Ограниченная версия репозитория для нового
GIV>На что только люди не готовы пойти чтоб только не убирать пароли из репозитория с исходниками? GIV>Положите пароли и прочие секреты в другое место, очевидное же решение.
Дело в том, что по факту пароли уже там есть. Нужно найти решение исходя их реальной ситуации, по факту. А вот как их хранить дальше это уже вторая проблема. Будем хранить однозначно отдельно. А сейчас нужно дать код программисту, сохранить версионность кода и не сломать основную БД.
Здравствуйте, WSA, Вы писали:
GIV>>На что только люди не готовы пойти чтоб только не убирать пароли из репозитория с исходниками? GIV>>Положите пароли и прочие секреты в другое место, очевидное же решение.
WSA>Дело в том, что по факту пароли уже там есть. Нужно найти решение исходя их реальной ситуации, по факту. А вот как их хранить дальше это уже вторая проблема. Будем хранить однозначно отдельно. А сейчас нужно дать код программисту, сохранить версионность кода и не сломать основную БД.
1. Поменять пароли в БД
2. Убрать пароли из репозитория с сырцами
3. Дать доступ к сырцам для девелоперов
Вроде все просто?
WBR, Igor Evgrafov
Re[3]: Mecrurial: Ограниченная версия репозитория для нового удалённого сотрудни
Здравствуйте, WSA, Вы писали:
WSA>А можно ли сделать эквивалентную копию репозитария, как бы с нуля, скопировав туда содержимое последней версии репозитория и мержить этот новый репозиторий с основным.... WSA>Ещё изучаю вариант ограничения пользователя репозитория, но кажется allow_read permission действует на весь репозиторий, былобы неплохо ограничить чтение default-ветки, а удалённому сотруднику открыть параллельную ветку и разрешить работать только с ней. Мержить с default-веткой без привлечения удалённого разработчика.
Сомневаюсь что выйдет что-то путное.
К тому же в какой-то момент захочется ведь смержить в обе стороны — из вашего основного в тот репозиторий для внешнего разработчика, чтобы у него были и ваши изменения, и тут можно опять упустить попадание туда паролей.
Так что проще и спокойнее сменить пароль все же.