Как мы можем улучшить наше развертывание и сборку систем?

Question

У нас есть 4 различных среды:

• Балетмейстер
• Dev
• Принятие пользователем
• 1010 * Живите *

Мы используем TFS, извлекаем последний код и удаляем его.
После завершения функции разработчики по отдельности загружают свои изменения в Staging. Если сайт стабилен (что определено по-настоящему неудачным тестированием), мы загружаем изменения в Dev, затем UserAcceptance и затем в прямом эфире.

Мы вообще не используем сборки / теги в нашем контроле исходного кода.

Что мне сказать руководству? Кажется, они не думают, что есть проблема, насколько я могу судить.

Answer 1

Если бы это было хорошо для вас, вы могли бы стать чемпионом Continuous Integration вашей компании. Вы могли бы провести некоторое исследование хорошего процесса для CI с TFS , написать предложенное решение, евангелизировать его своим коллегам-разработчикам и непосредственным менеджерам, пересмотреть его с их вкладом и передать его руководству. Или ты можешь просто сидеть и ничего не делать.

Я был в управлении в течение длительного времени. Я всегда ценю того, кто выявляет проблему и предлагает продуманное решение.

Answer 2

чей менеджмент? И как далеко они от вас?

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

Answer 3

Если у вас уже есть TFS, значит, вы почти у цели.

Я использовал TFS только для управления исходным кодом. У нас есть аналогичная установка с Dev / Stage / Prod. Я взял на себя обязательство установить сервер сборки. Как только это было сделано, я добавил возможность автоматического развертывания в dev для одного из моих проектов и рассказал об этом паре других парней. Первоначально прием был очень теплым.

Позже я добавил TFS Deployer к миксу и настроил его на автоматическое развертывание хорошей сборки dev на этапе.

В течение этого времени основная группа разработчиков постоянно боролась с тем, "Получили ли вы последние версии перед развертыванием в Stage или Production?" вопросы; мои вещи работали без помех. Поверьте мне, руководство и другие разработчики заметили.

Теперь (через 6 месяцев) у нас есть письменное правило, согласно которому вам даже не разрешено использовать команду «Опубликовать» в Visual Studio. ВСЕ проходит через сборку и развертывание CI. При переходе на prod наша производственная группа снимает соответствующую копию с сервера сборки. Я даже обучил нашу группу контроля качества тому, как проводить веб-тестирование, и мы постепенно интегрируем автоматизированные тесты во весь процесс.

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

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

Answer 4

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

2) Отсутствие четкой модели продвижения. Кажется, вы, ребята, перемещаете изменения между средами, а не "строите". Ключевое различие заключается в том, что если два изменения прекрасно работают в UAT из-за того, как они взаимодействуют, то если в производство будет внесено только одно изменение, оно может сломаться там. Продвижение согласованного кода - будь то его маркировка или просто архивирование всего веб-приложения и продвижение zip-файла - должно вызвать меньше проблем.

Я работаю над решением для непрерывной интеграции и развертывания, AnthillPro . То, как мы решаем эту проблему с помощью TFS, заключается в получении нового кода из TFS на основе отметки даты и времени (когда кто-то нажал кнопку «Доставить на сцену»).

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

Answer 5

В чем проблема? Как вы сказали, вы не можете сказать, видят ли руководство проблему. Возможно, они этого не делают! Скажите им, что вы видите в качестве текущей проблемы, и что вы бы порекомендовали для решения проблемы. Проблема заключается в том, что «наш текущий процесс потерпел неудачу 3 из 10 раз, и внедрение этого нового процесса уменьшило бы эти сбои до 1 из 10 раз».

Руководство должно видеть улучшения с точки зрения: снижения затрат, увеличения прибыли, сокращения времени, сокращения использования ресурсов. «Потому что это широко используемая лучшая практика» не будет достаточно. И это не так, «потому что это облегчает мою работу».

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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