TeamCity: как поместить неверсионные файлы конфигурации в извлеченный репозиторий?
Я использую репозиторий Git для управления версиями моего приложения. Моя структура проекта такова, что я использую файлы конфигурации, локализованные в каждой среде, в которой работает приложение. Эти локальные файлы конфигурации содержат такие вещи, как строки подключения SQL и другую информацию, относящуюся к каждой среде (каждая среда имеет свою собственную базу данных SQL Server, включая тестовую среду в Teamcity). Эти файлы не являются частью репозитория, но создаются заново, когда новый создается среда. В этой парадигме TeamCity - еще одна среда, и я создал конфигурационный файл для TeamCity для создания и запуска тестов NUnit для моего приложения.
мой вопрос: как я могу скопировать этот файл, который не находится под контролем источника, в папку, в которой TeamCity проверяет репозиторий? и как я могу это сделать, прежде чем TeamCity начнет создавать мое приложение? Я уверен, что это возможно, поскольку я читал здесь что "Параметры машины (например, настройка SSL-связи и т. д.) должен быть настроен на каждой машине с помощью проверки на стороне агента.- Как именно мне это сделать? Я не смог найти прямого ответа из документации.
Я прочитала этой теме это упоминает возможность использования нескольких корней, что означает, что он будет извлекать общедоступные источники из публичного репозитория и частные источники из частного репозитория с ограниченным доступом, а также доступ будет предоставлен только TeamCity. Это достойное решение, и я вижу, как это может быть проще в обслуживании, чем иметь пакетный файл или что-то, копирующее частные/локальные файлы каждый раз при запуске сборки, но по какой-то причине я не чувствую себя комфортно, ставя пароли и т. д. в репозитории. Я не уверен, почему у меня есть это предубеждение (просто кажется, что оно может быть уязвимым), и поэтому, если у кого-то есть опыт с любым или этими решениями, я хотел бы услышать о них. Я также хотел бы услышать мнения о хранении конфиденциальной информации в защищенном паролем хранилище. Это безопасная практика?
спасибо всем, кто может помочь.
PS: Я посмотрел на корневую страницу редактирования VCS и параметр" пользовательский каталог клонов на сервере", но я все еще не знаю, как скопировать файл в этот каталог. Изменяется ли рабочий каталог TeamCity или он остается неизменным?
2 ответов
Мне тоже не нравится вводить пароли в управление версиями, особенно не внешнее управление версиями, такое как Github.
Я просто помещаю файлы конфигурации где-то на машине сборки за пределами TeamCity и помещаю шаг командной строки в сборку, которая копирует их на место, прежде чем они понадобятся. В общем,
- установите "исполняемый файл команды" в программу копирования
- настройка "параметры" в исходный файл(Ы) и целевой справочник.
вам не нужно беспокоиться о том, где находится рабочий каталог TeamCity, так как текущий каталог шага командной строки будет вашим каталогом сборки, и вы можете использовать относительный путь в качестве цели.
Я не буду пытаться привести конкретные примеры, потому что я использую другой стек, чем вы, но я думаю, что тот же принцип должен работать.
Я закончил тем, что пошел по пути второго частного репозитория для хранения файлов конфигурации после изучения аспектов безопасности наличия общедоступного частного репозитория, который имеет конфиденциальную информацию. Эта техника описана здесь.
однако эта ссылка не решает основную проблему с использованием нескольких корней VCS-если правила проверки не изменены, Teamcity копирует первые файлы VCS в каталог проверки, удаляет все файлы, затем копирует вторые файлы VCS в тот же каталог. Я понятия не имею, почему это поведение было выбрано по умолчанию. Очевидно, что это приводит к сбою сборки, потому что исходных файлов кода больше нет.
решение описано здесь. В основном мне пришлось настроить правила проверки, чтобы переместить файлы, скопированные из первого корня VCS в подпапку, а затем иметь правила проверки на втором корне VCS, чтобы переместить файлы конфигурации в правильное расположение внутри этого вложенная папка.
теперь к основной проблеме: последствия для безопасности хранения конфиденциальной информации в общедоступном частном хранилище. Важное прилагательное здесь-публичное. Мое основное требование безопасности в этом сценарии заключается в том, что хранилище должно иметь столько же безопасности, сколько и папка Windows, защищенная с помощью вкладки безопасность. Аргумент, который я использую, чтобы оправдать, что он еще более безопасен, поскольку частный репозиторий Git использует HTTP или SSH безопасность, которая можно утверждать, так же сильна, если не сильнее, чем безопасность папок Windows, поскольку они более подвержены, чем папки Windows. Поскольку это просто будет хранить информацию для входа в тестовую среду, я не слишком беспокоюсь об этом. Вся конфиденциальная информация для моей производственной среды будет обрабатываться вручную. Но я открыт для мнений на эту тему. Надеюсь, это решение поможет другим людям. Пожалуйста, не стесняйтесь комментировать/задавать вопросы.