Частичные пакеты в непрерывной доставке

В настоящее время мы работаем над проектом C# (построенным на Sharepoint) и внедрили ряд автоматизированных процессов для помощи в доставке, вот подробности.

  1. Непрерывная интеграция. Типичная система CI для частой компиляции и развертывания в среде DEV.
  2. Частичный пакет. Каждую неделю определяется список дефектов, сопровождаемых исправлениями, и соответствующие сборки извлекаются из полного пакета для формирования частичного пакета. Частичный пакет развертывается и тестируется в последующих средах.

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

  1. Время сборки и развертывания слишком велико. На машинах разработчиков каждая модификация сборок вызывает повторное развертывание в IIS, которое занимает от 5 до 10 минут. Кроме того, для восстановления всего решения требуется 15 минут (или даже больше). (Самая болезненная часть этого проекта)
  2. Географическая разница. Каждая окончательная посылка доставляется в другой офис, поэтому ручная работа неизбежна, а размер посылки желательно небольшой.

Я буду очень признателен за ваше мнение, чтобы продвинуть практику непрерывной доставки вперед. Спасибо!


continuous-integration package continuous-delivery sharepoint
person user2741411    schedule 03.09.2013    source источник
comment
(Я бы предложил перенести это на Programers.stackexchange.com) - Несколько уточняющих вопросов - компиляция решения занимает 15 минут для компиляции на машинах разработчиков? Или на сборочной коробке?   -  person Rocklan    schedule 03.09.2013
comment
Это занимает 15 минут как на машине разработчика, так и на сборке. А в нашей команде из 30 человек создание чекина может занять более получаса.   -  person user2741411    schedule 03.09.2013
comment
Итак, ваш первый шаг — попытаться сократить время сборки. Вам нужно придумать способ предотвратить повторную компиляцию всего с нуля - только то, что изменилось. Возможно, вы можете разделить код на разные модули, которые можно скомпилировать, версионировать и, таким образом, вы можете ссылаться на двоичные объекты. Возможно, лучшее оборудование поможет.   -  person Rocklan    schedule 03.09.2013

Ответы (2)


arrow_upward
0
arrow_downward

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

Ограничьте круг вашей проблемы как можно более узким

«Слишком долго» — очень субъективный термин. Я знаю некоторые более крупные проекты, которые хотели бы увидеть 15-минутное время сборки. Учитывая ваш вопрос, невозможно узнать, возникла ли у вас проблема с конфигурацией или с инфраструктурой. Примером проблемы с конфигурацией может быть: используют ли ваши проекты все преимущества нескольких ядер за счет параллельной сборки / м переключатель? Примером проблемы с инфраструктурой может быть попытка перемещения больших объемов данных по медленной линии с использованием неэффективного или неисправного оборудования. Похоже, вы видите одно и то же время на разных машинах, поэтому вы можете сосредоточиться на настройке.

Разбейте сборку на «задачи», а каждую задачу — на максимально краткие этапы

Это в наибольшей степени поможет вам настроить конфигурацию и понять, что вам нужно для лучшей координации. Если вы создаете решение с использованием CI-сервера, вы, вероятно, используете такую ​​команду, как msbuild.exe OurProduct.sln, которая является правильным способом быстро запустить что-то, поэтому есть некоторая обратная связь. Но для оптимизации это решение нужно будет разбить на независимые проекты. Если вы найдете один проект, на который уходит больше всего времени, это может указывать на другие проблемы или может быть просто основным проектом, от которого зависит все остальное. То, как вы справляетесь со своими зависимостями задания сборки, зависит от вашего сервера CI и решения. Такой способ создаст больше координации с вашей стороны, но даст более быструю обратную связь, если это требуется, поскольку вы создаете только проект, в который были внесены изменения, а не полное решение.

Я не уверен, что вы имеете в виду о "географической разнице". Это "толчок" в офис или "вытягивание" из офиса? Это совсем другой вопрос. КАК вы получаете файлы там? И почему это требует ручного шага?

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

Лучший!

person Randolph    schedule 01.10.2013

arrow_upward
0
arrow_downward

Я не разработчик C#, но принципы остаются прежними.

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

С точки зрения развертывания — отлично, что вы его автоматизировали, но это звучит точно так же, как если бы вы создавали крупномасштабное развертывание. Можете ли вы придумать способ развертывания только дельт на сервере (серверах), развертываете ли вы один сжатый файл? Разбейте его, если это возможно.

person user924272    schedule 29.03.2014