ОК, я укушу. Есть технологический аспект этой проблемы, о котором уже говорили другие ответы. Но реальная проблема - это проблема process . Там, где реальное внимание должно быть уделено содержательному жизненному циклу разработки программного обеспечения (SDLC) - планированию, разработке, валидации и развертыванию. Я расскажу каждый по очереди. То, что вы хотите, это повторяемое действие на каждом этапе.
Планирование
Составление и запись того, что должно быть доставлено. Часто билетов или пользовательских историй достаточно. Иногда вы делаете больше, например, письменный документ с требованиями, на который подписывает заказчик, и это переводится на различные артефакты, такие как письменные сценарии использования - в конечном итоге вы хотите получить что-то, записанное в электронной системе, где вы можете связать изменения в коде с ним. Что приводит меня к ...
Разработка
Помните эту электронную систему? Хорошо. Теперь, когда вы вносите изменения в код (вы берете на себя обязательство по управлению исходным кодом?), Вы связываете эти изменения с чем-то в этой электронной системе - как правило, с билетами. Мне нравится Trac , но я также слышал хорошие вещи о номере Атлассиана . Это дает вам прослеживаемость . Таким образом, вы можете утверждать, что было сделано и как. Затем вы можете использовать эту систему и систему контроля версий для создания сборки - всех битов, необходимых для всего, что изменилось - и тега , которые встроены в систему контроля версий - это ваш список того, что изменилось. Более того, сборка содержит всего , так что это отдельная сущность, которую можно легко развернуть самостоятельно. Затем сборка доставляется за ...
Проверка
Пожалуй, самый важный шаг, который многие магазины игнорируют - на свой страх и риск. Дефекты, обнаруженные в процессе производства, экспоненциально дороже устранить, чем когда они были обнаружены ранее в процессе. И проверка часто является единственным шагом, когда это происходит во многих магазинах - , поэтому убедитесь, что ваш делает это .
Это не должно быть сделано программистом ! Это как лиса, наблюдающая за курятником. И тот, кто делает это, должен следовать какому-то плану. Мы используем Test Link . Это означает, что каждая сборка проверяется одинаково, поэтому вы можете идентифицировать регрессия ошибок. И эта сборка должна быть развернута так же, как и в production .
Если все идет хорошо (обычно требуется минимум 3 сборки), сборка проверена . И это идет к ...
Развертывание * * тысяча пятьдесят-одна
Это должно быть не событие, потому что вы выполняете проверенную сборку, выполняя те же действия, что и при тестировании. Возможно, сначала он попадет на промежуточный сервер, где есть процесс автоматического копирования, но суть в том, что на этом этапе проблема не должна возникать, поскольку вы прошли валидацию с помощью того же процесса.
Заключение
С точки зрения знание что и где, то, что вы действительно хотите, - это логический способ группировки изменений вместе. Вот тут и возникает идея build . Это действительно блок, который должен переходить между этапами в SDLC. Если у вас уже есть это, тогда способность понять состояние данной системы становится тривиальной.