Любая команда из полутора человек и более использует инструменты совместной разработки. Вот инструменты нашего проекта: CVS, CruiseControl.NET, TestTrack. Кроме того, есть еще множество специализированных инструментов разработки, которые должны быть стандартными во всей команде. Для нас это: NUnit, NAnt, Selenium-RC. Добавьте к этому списку еще и все внешние библиотеки, которые вы используете.

Весь этот зоопарк время от времени нужно апгрейдить. CVS нужно менять на Subversion чтобы отказаться, наконец, от ведения change log’ов модулей вручную. Надо апгрейдить NAnt до версии 0.85 rc4, которая корректно работает с NUnit. Надо переписывать старые функциональные тесты на Selenium-RC, а сам Selenium-RC – апгрейдить до следующей версии. TestTrack надо было апгрейдить еще 5 лет назад, но не получается – политика.

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

Пока идеи следующие:

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

Небольшое уточнение. Эти размышления не затрагивают вопрос обновления платформы разработки. Кроме того, предполагается, что вы пользуетесь open source продуктами либо имеете возможность бесплатно апгрейдить свои коммерческие продукты. Процесс небесплатного обновления коммерческих продуктов выглядит совсем по-другому и выходит за рамки данных размышлений.