Какие изменения требуют повторного развертывания зависимой сборки? - PullRequest
7 голосов
/ 03 ноября 2011

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

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

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

  • Постоянные изменения
  • Изменения определения перечисления (порядок значений)
  • Возвращается тип изменения функции, и вызывающая сторона использует var (иногда)
  • Пространство имен класса изменяется на другое, уже упоминаемое пространство имен.

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

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

Таким образом, все, что нарушает компиляцию, будет обнаружено (изменение имени метода и т. д.), поскольку они требуют изменений в вызывающем коде.

Ответы [ 2 ]

6 голосов
/ 03 ноября 2011

Вот еще один:

Изменяет необязательные значения параметров.

Значения по умолчанию компилируются непосредственно в сборку с использованием их (если не указано)

 public void MyOptMethod(int optInt = 5) {}

Любой код вызова, такой как этот:

 theClass.MyOptMethod();

Будет скомпилировано в:

 theClass.MyOptMethod(5);

Если вы измените метод на:

 public void MyOptMethod(int optInt = 10) {}

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


Дополнительные изменения, которые потребуют перекомпиляции (спасибо Polynomial):

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

Итак - всегда перекомпилировать все .

2 голосов
/ 03 ноября 2011

Во-первых, у нас иногда развертывается только несколько сборок в приложении вместо полного приложения.Однако это ни в коем случае не является нормой и ТОЛЬКО было сделано в наших тестовых средах, когда разработчик совсем недавно (как в течение последних нескольких минут) опубликовал весь сайт и просто вносил незначительные изменения.Однако, как только разработчик будет удовлетворен, он продолжит полную перекомпиляцию и повторную публикацию.

Последний шаг к тестированию всегда основан на полной перекомпиляции / развертывании.Толчки к постановке и в конечном итоге производству основаны на этой полной копии.

Помимо повторяемости, одна из причин в том, что вы не можете быть на 100% уверены, что человек не упустил что-то в сравнениях.Далее, количество времени для развертывания 100 сборок против 5 является тривиальным и, откровенно говоря, не стоит того человеческого времени, которое требуется, чтобы попытаться выяснить, что действительно изменилось.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...