Как хранить код в системе контроля версий?

Как хранить код в системе контроля версий?

Разработчик дружелюбен ? чтобы программист мог быстро взять последнюю версию и запустить из своего редактора, не внося много изменений? (как файлы конфигурации, указывающие на dev DB..etc)

или

Должно ли это быть дружественным к производству ? источник должен быть таким, чтобы его можно было легко развернуть в производственной среде, а когда разработчик использует последнюю версию, он должен вносить изменения в соответствии со своими потребностями разработки.

Почему выбирают? Это должно быть как.

Ваша среда разработки должна быть настроена так, чтобы ее можно было легко проверить, открыть, собрать, запустить, отладить (например, без абсолютного пути!). Это можно легко сделать с помощью директив компиляции, внедрения класса конфигурации + зависимости или даже таких хитростей, как perso.config в ASP.NET.

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

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

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

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

Конечно, это действительно актуально только для разработки под Windows.

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

Это должно быть удобно для производства, в противном случае проблематично поддерживать автоматизированные сборки.

Я за снижение трения, чтобы было легче выполнять работу, но вам также нужно учитывать режимы отказов.

Если исходная версия репозитория всегда настроена для производственного использования, каков результат того, что разработчик не смог перенастроить перед запуском системы? Разработчик запускает код против производства.

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

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

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

Определенно дружественный к разработчику, со скриптами для автоматизации изменений для обеспечения качества и производства.

Почему бы не иметь ветку (в зависимости от того, какой контроль версий вы используете - я использую Git) для развертываемого кода и другую для версии, готовой для разработчика? Это звучит намного лучше и не так сложно настроить.

Вы можете работать и фиксировать свои изменения, а затем объединить их в развертываемую версию.