Hotfix что такое: что это такое, для чего используется и как правильно установить?

• 20.04.2016
• 13 минут на чтение

В этой статье

Применимо к: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

В этом разделе описаны типы обновлений, доступных для Microsoft Dynamics AX 2012, и процесс развертывания обновлений.Обновления включают исправления, накопительные обновления, пакеты обновления и пакеты функций.

Важно

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

Из-за уникальной архитектуры реализаций Microsoft Dynamics AX многие проблемы могут возникнуть при установке исправления кода.Мы рекомендуем вам протестировать все бизнес-сценарии и настройки, чтобы убедиться, что обновление работает должным образом, что обновление не влияет на другие области и что полученные данные верны.

Этот раздел дополняет информацию, включенную в определенные обновления.

Процесс развертывания обновлений

Различные обновления могут влиять на разные компоненты Microsoft Dynamics AX. При установке обновления программа установки обновления указывает, какие компоненты Microsoft Dynamics AX затронуты обновлением.

Если обновление затрагивает несколько компонентов, мы рекомендуем выполнить следующие действия, чтобы применить обновление:

1. Примените обновления базы данных к одной базе данных, примените обновления Application Object Server (AOS) к одному локальному экземпляру AOS, связанному с обновленной базой данных, и примените обновления клиента к одному локальному клиенту. Затем запустите среду и проверьте все бизнес-сценарии.

   Важно

   Поскольку хранилище моделей в Microsoft Dynamics AX 2012 и Microsoft Dynamics AX 2012 Feature Pack является частью бизнес-базы данных, при обновлении базы данных вы также импортируете все обновления кода.

2. Примените обновления базы данных к любым дополнительным базам данных путем экспорта и импорта хранилища моделей. После того, как ваша система будет скомпилирована в тестовой среде, мы рекомендуем использовать командлеты Windows PowerShell Import-AXModelStore для развертывания изменений в производственной среде. Такой подход требует минимального простоя вашей производственной системы. Для получения дополнительной информации см. Развертывание настроек в средах Microsoft Dynamics AX 2012 (официальный документ).

3. Примените обновления AOS ко всем дополнительным экземплярам AOS.

   Важно

   Невозможно применить обновления к удаленным экземплярам AOS с помощью AXUpdate.exe. Вы должны применить обновления локально.

4. Разверните изменения в службах отчетов Microsoft SQL Server, а затем в корпоративном портале для Microsoft Dynamics AX.

5. Внесите изменения в любые розничные компоненты.

6. Массовое развертывание обновлений для ваших клиентов. Для получения дополнительной информации см. Запуск AXUpdate в автоматическом режиме.

Важно

Мы настоятельно рекомендуем обновлять все компьютеры в среде вместе.

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

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

Оцените обновление и определите, какие типы исправлений оно содержит.

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

Примечание

Если вы настраивали свою среду до получения обновления, внимательно прочтите статью базы знаний, в которой это описано. Изучите все объекты, на которые влияет исправление, чтобы определить, следует ли объединить изменения, реализованные исправлением, с настройками на более высоком уровне, например BUS, VAR, USR или CUS.

Чтобы определить, какой тип исправления содержит обновление, см. Раздел Применение обновлений и исправлений

Чтобы определить номер сборки используемой вами версии Microsoft Dynamics AX, см. Раздел Как определить, какую версию и номер сборки я использую?

Microsoft Dynamics AX 2012 R3:

Microsoft Dynamics AX 2012 R2 (основная поддержка завершена):

Microsoft Dynamics AX 2012 (основная поддержка завершена):

Подготовка к обновлению

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

• Создайте резервную копию обновляемой базы данных. Создав резервную копию базы данных, вы можете вернуться к известной и надежной версии, если это необходимо. Таким образом можно сократить время простоя в случае возникновения непредвиденной ошибки. Дополнительные сведения см. В разделе Резервное копирование и восстановление баз данных (SQL Server).

• Запланируйте время, когда это затронет наименьшее количество пользователей системы или ни одного пользователя. Рекомендуется заранее объявить время обновления, чтобы пользователи знали об ожидающем обновлении и ожидаемом времени простоя.Уведомив всех пользователей о времени обновления, вы можете минимизировать потерю данных, повреждение данных и потерю производительности.

• Убедитесь, что система работает в однопользовательском режиме, пока установлено исправление, и что только администратор назначен для выполнения обновления. Поскольку изменения в коде могут повлиять на Application Object Server (AOS), изменения могут повлиять на пользователей, которые в настоящее время находятся в системе.

  Предупреждение

  Изменения в приложении могут потребовать компиляции или синхронизации приложения.Эти операции увеличивают время простоя.

Установить обновление

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

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

Проверить обновление

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

• Изменение, внесенное обновлением, работает должным образом.

• Изменение не коснулось других областей системы.

• Приложение Microsoft Dynamics AX в целом работает должным образом.

Накатить обновление в производственную среду

После тестирования обновления вы должны установить его в производственной среде.Вы должны установить все двоичные исправления и исправления предварительной обработки, но вы можете откатить изменения кода до производственной среды, импортировав и экспортировав хранилище моделей. Используйте методологию, описанную в разделах «Развертывание настроек в средах Microsoft Dynamics AX 2012» (официальный документ) и «Как экспортировать и импортировать хранилище моделей». Экспортируя и импортируя хранилище моделей, вы можете избежать компиляции кода в производственной среде.

В чем разница между исправлением, накопительным обновлением, пакетом обновления и пакетом функций?

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

Исправления

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

Корпорация Майкрософт публикует соответствующие статьи базы знаний (KB) для каждого исправления, выпущенного для каждого продукта Microsoft.Эти продукты включают Microsoft Dynamics AX. В этих статьях базы знаний описываются изменения, вносимые исправлением в объекты, таблицы или файлы базы данных, или другой код. Каждое исправление выпускается для решения конкретной проблемы или сценария восстановления нормальной работы программного обеспечения. Вы должны просмотреть соответствующую статью базы знаний, чтобы оценить, нужно ли применять исправление в вашей реализации Microsoft Dynamics AX.

Накопительные обновления

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

При планировании развертывания, в котором будет использоваться какое-либо из отраслевых решений, мы рекомендуем установить отраслевое решение перед установкой накопительных обновлений.

Важно

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

Пакеты обновлений

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

Пакеты функций

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

Как узнать, какое исправление я устанавливаю?

Microsoft Dynamics AX имеет следующие стандартные типы исправлений:

• Двоичные исправления. Объекты и компоненты, которые устанавливаются с помощью стандартных файлов установщика Windows (MSI), исправляются с помощью файлов исправлений установщика Windows (MSP) и применяются с помощью AXUpdate.Exe. Эти обновления являются накопительными: каждое двоичное исправление содержит изменения из всех ранее выпущенных исправлений.

• Исправления приложений. Исправления приложений — это исправления, которые предоставляются с использованием файлов модели приложения (.axmodel) на любом из уровней исправлений приложений Microsoft (SYP, GLP, FPP, SLP). В отличие от бинарных исправлений, исправления приложений предназначены для конкретного исправления.

  Важно

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

  • Все файлы моделей исправлений приложений должны быть установлены с помощью AXUpdate.exe; импорт этих моделей приложений вручную явно не поддерживается и может вызвать ошибки.

• Исправления с предварительной обработкой — исправления с предварительной обработкой применяются к сценариям обновления данных (например, DatabaseUpgrade), которые запускаются в системах Microsoft Dynamics AX 4.0 и Microsoft Dynamics AX 2009 перед обновлением до Microsoft Dynamics AX 2012.

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

В следующей таблице описано назначение каждого файла и папки.

Как узнать, содержит ли исправление приложения отчеты или веб-части?

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

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

Версия Microsoft Dynamics AX, которую вы используете, отображается в форме О Microsoft Dynamics AX . Вы можете открыть эту форму из меню Help .

В зависимости от версии и установленных решений перечислены некоторые или все из следующих типов версий:

• Версия ядра

• Версия приложения

• Версия решения

Чтобы определить значение номера версии, которую вы используете, см. Сообщение в блоге Обзор номеров сборок Microsoft Dynamics AX.

Когда мне следует использовать мастер анализа воздействия (AXImpactAnalysis)?

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

Что такое магазин базовой модели?

Хранилище базовой модели — это база данных, имеющая ту же схему, что и хранилище модели. Он используется при применении обновлений и во время обновлений. Во время процесса обновления мастер анализа воздействия использует хранилище базовой модели для хранения обновлений приложения перед их применением, чтобы их можно было сравнить с существующим кодом.При обновлении с Microsoft Dynamics AX 2009 или Microsoft Dynamics AX 4.0 элемент Обнаружение конфликтов обновления кода Элемент в контрольном списке обновления кода использует хранилище базовой модели после того, как вы импортировали в него существующие файлы .xpo.

Содержимое хранилища базовой модели перезаписывается во время процесса обновления.

Что означает название пакета обновления?

Для пакетов, обслуживающих Microsoft Dynamics AX, используется следующее соглашение об именах: -KB – .Exe.

Например, пакет может называться DynamicsAX2012-KB123456- SP2.exe. В следующей таблице поясняются сегменты имен, которые используются в именах пакетов.

См. Также

Плакаты с техническими схемами для Microsoft Dynamics AX 2012

Путь к развертыванию без исправлений

Мы, моя команда и я боялись повторного развертывания! Представьте, что вместо того, чтобы работать над функцией, вам нужно повторно развернуть систему: управление версиями, попросить мастера схватки написать запрос на изменение, упаковать систему, обратиться к группе ИТ-операций и попросить их помощи в развертывании. В конце концов, диаграмма выгорания выглядит плохо, и заинтересованные стороны недовольны.

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

Но ошибки везде

За свою карьеру в качестве инженера-программиста я был свидетелем множества ошибок, или того, что инженеры называют «ошибками». Они могут быть где угодно: на сервере, в клиенте, в браузере, в сетевом оборудовании!

Ошибки не только повсюду, но и стоят дорого.Их сложно найти, имитировать и исправить — этот процесс называется отладкой. НАСА однажды столкнулось с одной из самых дорогостоящих из когда-либо обнаруженных ошибок, испарив 125 миллионов долларов в тонкой атмосфере Марса.

Но, «люди делают ошибки», — сказал Том Гэвин, администратор Лаборатории реактивного движения проекта НАСА. К сожалению, сама природа разработки программного обеспечения затрудняет обнаружение потенциальных ошибок на ранних этапах разработки.

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

1. Время разработки
2. Время перед развертыванием
3. Время после развертывания

Время разработки

Все начинается с ясного рассказа

Хороший рассказ включает хорошее определение «готово» и хорошую разбивку рассказа. Хорошая история поможет команде:

1. Уменьшить двусмысленность.
2. Помогите команде понять цель истории.
3. Ускорьте процесс разработки.
4. Поддержка лучшего качества доставки.

Хорошая история начинается с хорошего названия, обычно в формате:

Как [роль] я хочу [активность], поэтому [цель / ценность]

Далее, у него есть хорошее определение готового. Определение «готово» сообщает команде инженеров о каждом тестируемом сценарии, который необходимо учесть, чтобы история считалась доставляемой.Определение done написано владельцем продукта и будет проверено им.

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

Плохие истории имеют несколько общих характеристик:

1. Неясно; какова цель этой истории?
2. Отсутствует пример каркаса.Даже простой: только ожидаемый результат.
3. Неоднозначное определение слова done. Не уверен, чего ожидать.

Например, рассказ об изменении в системе A, но не упоминается, что изменение повлияет на систему B, поддерживаемую той же командой. Следовательно, баг! Но как этого избежать, если система B обслуживается другой командой? Мы исследуем это ниже.

Культура без спешки

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

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

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

Лучше выполнить успешное развертывание один раз, чем запускать в спешке и много раз терпеть неудачу.

Главное — знать, как назначить приоритет. Как?

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

Есть функции, исправления, а также ошибки, которые требуют быстрого реагирования, главное — расставить приоритеты! Обычно у нас есть четыре уровня приоритета: P0, P1, P2 и P3.

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

Выше P1 — P0. P0 очень и очень тревожный. Это сделает систему совершенно бесполезной. Это могло рассердить многих клиентов. Это может обанкротить вашу компанию. Если вам нужно выпрыгнуть из кровати, сделайте это.

Одним из примеров ошибки P0 является состояние после развертывания, когда система экспоненциально потребляет пространство памяти, что приводит к снижению производительности, и все пользователи больше не могут надежно получить доступ к системе. Для этого нужен ответ «все руки на палубу», быстрое решение проблемы (без паники) и развертывание исправления как можно скорее.

P2 — для текущего спринта. Все P2 — это истории, которые были продуманы задолго до начала спринта и были запланированы для включения в этот спринт.

Ниже P2 находится P3, он может подождать, пока не будет запланирован будущий спринт. Как узнать, относится ли история к P3? Что ж, если есть какие-то другие средства для достижения результата без развертывания запрошенной истории, тогда история может подождать. Сделайте P3 по умолчанию. Всегда старайтесь отдавать приоритет P3 всем запросам на незапланированные функции / исправления ошибок.

Следуя этим рекомендациям, у меня гораздо лучшее настроение, и команда пишет меньше ошибочного кода.

Надлежащая практика кодирования

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

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

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

Контроль качества

Самый важный аспект контроля качества — это тестирование. Существует множество видов тестирования: интеграция, модульное тестирование, черный ящик, белый ящик, приемочное тестирование пользователя (UAT). Тестирование не подлежит обсуждению. К сожалению, это часто бывает.

Игнорирование тестов означает накопление технического долга.Со временем процесс разработки будет ухудшаться, так как им придется беспокоиться о том, что их код нарушит другие части их собственного кода. Даже при прохождении тестов мы все равно находим ошибки, как черт возьми! Джикстра сказал:

Тестирование никогда не доказывает отсутствие неисправностей, а только показывает их наличие.

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

Хорошее эмпирическое правило — охват 85% или выше; Это означает, что ваши тесты должны охватывать как минимум 85% вашего кода.

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

Не менее важно, чем покрытие кода, но вам следует интегрировать в свою кодовую базу набор инструментов непрерывной сборки, например Travis CI, Drone или Codeship.Таким образом, любые изменения в ветке должны запускать тесты. Когда тесты пройдут, для вас будет создан пакет. CI стремится максимизировать вашу эффективность.

Как владелец продукта, не идите на компромисс при тестировании! Проведя очень тщательное тестирование, мы смогли обнаружить ошибку P0 при тестировании нашего пакета в производственной среде! То есть после 2–3-кратного запуска тестов как в промежуточной среде, так и в производственной среде.

Синхронизация работы

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

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

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

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

Охота на старые ошибки

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

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

Раньше нам звонили из финансового отдела по поводу «ошибок», связанных с функцией, которые на самом деле были вызваны их собственной ошибкой, например, неправильным нажатием кнопки отмены вместо кнопки «Готово» после того, как деньги были переведены на счет продавца. , Чтобы отменить такой щелчок, нам нужно вручную внести несколько сложных изменений в данные, которые в конечном итоге истощили нашу энергию.Однако после того, как мы посвятили два хороших спринта для отладки, нам больше никогда не приходилось делать эту неприятную ручную работу! Ницца! Мы забыли, насколько это было напряженно. Мы наверняка стали счастливее.

Автономность

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

Такой инструмент, как Trello, Pivotal Tracker, Asana или даже старая добрая доска, можно использовать для перечисления всех функций, которые будут разработаны в текущем спринте, а затем позволить любому назначить себя для истории.Пока история соответствует текущей цели компании в контексте команды, не должно быть необходимости назначать работу менеджером — пусть люди сами назначают.

PS. Если вы вообще не заинтересованы в работе над какой-либо историей, тогда это еще одна «история» для вас, и HR будет (не) счастлив встретиться и увидеть вас.

Но, например, если, обладая автономией, ни один человек не захочет развить определенную функцию; тогда product owner должен хорошо обсудить проблему.Если никто не хочет, пусть люди объединятся для рассказа. Я никогда не сталкивался с ситуацией, когда никто не хотел бы рассказывать истории во имя автономии.

Время перед развертыванием

Запросы на извлечение и проверка кода

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

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

Проверка кода не должна быть частью определения «готово», так же как и тестирование тоже не должно быть частью этого определения. Проверка и тестирование кода должны быть второй натурой для разработчиков программного обеспечения. Ни одна история не может быть развернута без проверки кода или тестирования! Так что писать это в определении done излишне.

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

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

Время развертывания

Небольшое развертывание, частое развертывание

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

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

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

Тест по постановке. Тест на публике.

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

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

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

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

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

Время после развертывания

Использовать систему отслеживания и мониторинга ошибок

— Какие исправления Tridion были применены?

1. Товары
2. Клиенты
3. Случаи использования

1. Переполнение стека Общественные вопросы и ответы
2. Команды Частные вопросы и ответы для вашей команды
3. предприятие Частные вопросы и ответы для вашего предприятия
4. работы Программирование и связанные с ним технические возможности карьерного роста
5. Талант Нанять технических талантов
6. реклама Обратитесь к разработчикам по всему миру

Загрузка…

2. Авторизоваться зарегистрироваться

3. текущее сообщество

   • Переполнение стека Помогите чат