Как выпустить подмножество результатов?

Если вы не подумали об этом заранее, сделать это довольно сложно.

Но в будущем вы можете настроить себя на это следующим образом:

1. Получите настоящую систему контроля версий с очень хорошей поддержкой как ветвления, так и слияния. Исторически это означало что-то вроде git или Mercurial, потому что поддержка слияния Subversion была очень слабой. (Однако команда Subversion недавно работала над улучшением своей поддержки слияния.) Что касается Windows, я не знаю, какие инструменты VC лучше всего подходят для чего-то вроде этого.

2. Решите, как организовать работу над отдельными функциями. Один из подходов - сохранить каждую функцию в отдельной ветке и объединить ее с основной веткой только тогда, когда новая функция будет готова. Наша цель - сделать так, чтобы основная ветвь была почти доступной для доставки в любое время. Это проще всего, когда ветки функций не сидят и не собирают пыль - возможно, каждый программист сможет работать только над одной или двумя функциями за раз и объединить их, как только они будут готовы?

В качестве альтернативы вы можете попробовать выбрать отдельные исправления из своей истории контроля версий. Это утомительно и подвержено ошибкам, но это может быть возможно для некоторых очень дисциплинированных групп разработчиков, которые пишут очень чистые патчи, которые вносят ровно одно полное изменение. Вы видите этот тип патча в сообществе ядра Linux. Попробуйте посмотреть некоторые патчи на Linux 2.6 gitweb, чтобы увидеть, как выглядит этот стиль разработки.

Если у вас возникли проблемы с тем, чтобы ваш багажник всегда оставался «почти готовым к доставке», вы можете прочитать книгу по гибкому программированию, например Объяснение экстремального программирования. Все ветвления и слияния в мире будут бесполезны, если ваш новый код будет содержать много ошибок и потребует длительных периодов тестирования для поиска основных логических ошибок.

Обновления

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

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

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

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

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

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

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

Другая, но довольно успешная стратегия, которую я использовал в прошлом, - это сделать сами функции настраиваемыми и просто развернуть их как отключенные для незавершенных функций или для клиентов, которые еще не хотят использовать определенные функции.

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

Это просто, там сделано такое:

1. Создайте ответвление выпуска 2/3 от вашей текущей основной ветки.
2. В ветке выпуска 2/3 удалите ненужные функции.
3. Стабилизируйте ветвь выпуска 2/3.
4. Назовите версию My Product 2.1 2/3.
5. Релиз из ветки релиза 2/3.
6. Вернитесь к разработке в основной ветке.