Здравствуйте,

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

При подготовке билдов для различных сред делаем чекин и меняем вручную все параметры.

Как-то это некрасиво.

Есть решение создать набор этих конфигурационных файлов и подкладывать их в нужное время в нужный билд, это сократит риск ошибок.

Какие существуют еще варианты для сборки такого приложения?

Здравствуйте, yev, Вы писали:

yev>Здравствуйте,

yev>Есть веб-проект с некоторым количеством конфигурационных файлов. Значения параметров в этих файлах зависят от среды (дев, тестовый сервер, интеграция, продакшн).

...

yev>Какие существуют еще варианты для сборки такого приложения?

А отрастить по одной ветке для каждого типа среды пробовали? Одна ветка — на дев, другая а тест, третья — на продакшн и т.п. Какую систему контроля версии юзаете?

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

Здравствуйте, yev, Вы писали:

yev>И ветки, по-хорошему, нужны ведь для различных версий продукта.

Ну это только один, довольно консервативный, вариант.
У нас ветка на каждого девелопера, которая мерджится на ветку для интеграции,
из которой уже все мерджится на главную ветку версии.
И все под контролем без каких-либо серьезных конфликтов.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, yev, Вы писали:

yev>>И ветки, по-хорошему, нужны ведь для различных версий продукта.

А>Ну это только один, довольно консервативный, вариант.
А>У нас ветка на каждого девелопера, которая мерджится на ветку для интеграции,
А>из которой уже все мерджится на главную ветку версии.
А>И все под контролем без каких-либо серьезных конфликтов.

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

Здравствуйте, yev, Вы писали:

yev>Да, но при таком использовании вы теряете все выгоды системы контроля версий!
yev>Получается, что программист работает с кодом системы в изоляции от других. И все ошибки, будут найдены, если повезет, только при интеграции, а не при очередном комите или апдейте.
yev>Таким образом, нарушается принцип быстрого нахождения и исправления конфликтных ситуаций. Чем быстрее обнаружен конфликт, тем меньше цена его исправления!

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

Если же разработчику нужно несколько недель, чтобы что-то закончить,
то я даже и не вижу, как можно иначе, не мешая другим, организовать работу,
кроме как дать ему отдельную ветку.

Здравствуйте, yev, Вы писали:

yev>Здравствуйте,

yev>Есть веб-проект с некоторым количеством конфигурационных файлов. Значения параметров в этих файлах зависят от среды (дев, тестовый сервер, интеграция, продакшн).
yev>В настояший момент в системе контроля версиями конфигурационные файлы "настроены" на сервер интеграции. Программисты чекинят проект и изменяют параметры на дев. окружение и в дальнейшем эти файлы не комитят.

yev>При подготовке билдов для различных сред делаем чекин и меняем вручную все параметры.

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

Здравствуйте, Edge, Вы писали:

E>Здравствуйте, yev, Вы писали:

yev>>Здравствуйте,

yev>>Есть веб-проект с некоторым количеством конфигурационных файлов. Значения параметров в этих файлах зависят от среды (дев, тестовый сервер, интеграция, продакшн).
yev>>В настояший момент в системе контроля версиями конфигурационные файлы "настроены" на сервер интеграции. Программисты чекинят проект и изменяют параметры на дев. окружение и в дальнейшем эти файлы не комитят.

yev>>При подготовке билдов для различных сред делаем чекин и меняем вручную все параметры.

E>Можно завести для параметров переменные окружения и грузить их при старте сборки в зависимости от того, что нужно собрать. А в сборочном скрипте просто подставлять значения из переменных в файлы конфигурации.

Спасибо за идею. Интересно. А есть ли у Вас примерчик такого сборочного скрипта?

Здравствуйте, yev, Вы писали:

yev>Используем SVN.
yev>Но тогда будет небходимо синхронизировать код между всеми ветками. Если пофиксили баг в дев-ветке, то нужно будет мержить дев с другими ветками...
yev>Не красиво.
yev>И ветки, по-хорошему, нужны ведь для различных версий продукта.

насколько я знаю в SVN можно настроить линки — тогда у вас будет одна главная реальная ветка с кодом и N веток для разных сред, из которых будет залинкована реальная ветка.

т.о. никакая синхронизация будет не нужна.

Спасибо.
К.

JD>насколько я знаю в SVN можно настроить линки — тогда у вас будет одна главная реальная ветка с кодом и N веток для разных сред, из которых будет залинкована реальная ветка.

JD>т.о. никакая синхронизация будет не нужна.

Можно про линки поподробнее? что-то я ничего похожего не припоминаю/не нахожу.

А>>Ну это только один, довольно консервативный, вариант.
А>>У нас ветка на каждого девелопера, которая мерджится на ветку для интеграции,
А>>из которой уже все мерджится на главную ветку версии.
А>>И все под контролем без каких-либо серьезных конфликтов.

yev>Да, но при таком использовании вы теряете все выгоды системы контроля версий!

Микрософт именно так собирает Windows.

yev>Таким образом, нарушается принцип быстрого нахождения и исправления конфликтных ситуаций. Чем быстрее обнаружен конфликт, тем меньше цена его исправления!

Ни на чем не основанное голословие.

Здравствуйте, yev, Вы писали:

E>>Можно завести для параметров переменные окружения и грузить их при старте сборки в зависимости от того, что нужно собрать. А в сборочном скрипте просто подставлять значения из переменных в файлы конфигурации.

yev>Спасибо за идею. Интересно. А есть ли у Вас примерчик такого сборочного скрипта?

Примерчика к сожалению никак, но могу объяснить на пальцах. Вот примерный рецепт для Visual Studio:

1. Запускаете cmd
2. Пишете "SET SOME_INCLUDE=c:\includepath" У вас появляется переменная окружения SOME_INCLUDE, ее можно увидеть командой SET
3. Из этой командной строки можно запустить студию ..\devenv.exe, если посмотреть переменные окружения её процесса, то там будет SOME_INCLUDE
4. Теперь в свойствах C++ проекта можно использовать макрос "$(SOME_INCLUDE)". Если его написать в С/С++ -> General -> Additional Include Directories, то макрос развернется и у вас появится там директория c:\includepath. Ну и так далее, макросы можно указывать везде, где можно прописать пути.

Ну а дальше простор для творчества — команды SET можно вынести в отдельный командный файл, да много всего можно сделать.

Здравствуйте, Maxim Golov, Вы писали:

MG>Можно про линки поподробнее? что-то я ничего похожего не припоминаю/не нахожу.

Похоже он говорит про проперти svn:externals