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

Question

В дополнение к моему вопросу на случайно выпущен код-как-то-жить-как-предотвратить-повторение . После клиентского UAT клиент часто говорит, что он рад, что подмножество функций будет выпущено, а другие - в будущем.

Мой вопрос: «Как вы выпускаете 2/3 (две из 3) своих функций». Мне было бы интересно узнать, как крупные игроки, такие как Microsoft, справляются с такими ситуациями, как ... «Правильно, мы только выпустим 45/50 первоначально предложенных функций / исправлений в следующей версии Word, упакуем их и отправим».

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

Как вы выпускаете 2/3 разработанных вами функций?

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

- Ли

Answer 1

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

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

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

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

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

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

Обновление

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

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

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

Answer 2

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

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

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

Answer 3

Это легко, было сделано это:

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

Answer 4

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

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

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