Процесс развертывания сборки Windchill Navigate
Процесс развертывания включает в себя отправку и продвижение пакетов в различных средах. Его цель состоит в том, чтобы обеспечить тщательное тестирование и проверку пакета на каждом этапе, прежде чем он попадет в среду окончательного развертывания.
Процесс развертывания Navigate включает следующие шаги.
1. Первоначальное развертывание в среде более низкого уровня
2. Этап кривой готовности
3. Окончательное развертывание в производственной среде
Рассмотрим следующий сценарий. Коллектив выбирает вариант использования согласно текущим требованиям, а затем интегрирует его в цикл спринта. Процесс включает в себя отправку и продвижение пакета на различных этапах. Первоначально пакет развертывается в среде более низкого уровня путем его отправки. Пакет продвигается на этап кривой готовности. Окончательное продвижение происходит на заключительном этапе развертывания.
Подробное описание процесса
1. Первое/начальное развертывание сборки - начальное развертывание сборки, которое PTC получает от клиента, проходит тщательную проверку коллективом PTC. Для этой проверки необходимы следующие артефакты.
◦ Заполненная анкета - подробная анкета, заполненная клиентом.
◦ Пакет сборки - ZIP-пакет, отправленный клиентами и/или системными интеграторами.
 | Начальная сборка переходит к следующему шагу, только если коллектив PTC утвердит ее и убедится в ее соответствии требуемым рекомендациям. |
2. Этап кривой подготовки - этот этап не требует утверждения коллективом PTC. На этом этапе сборка проходит кривую подготовки, которая включает в себя следующие задания.
◦ Устранение ошибок - выявление и устранение проблем.
◦ Изменения логики - доработка функциональности сборки.
◦ Приемочное пользовательское тестирование (UAT) - обеспечение соответствия сборки требованиям пользователей.
◦ Косметические изменения - корректировка интерфейса пользователя и взаимодействий с пользователем.
Начальное развертывание выполняется в непроизводственной среде. Клиент или системный интегратор несет ответственность за ведение полного документирования всех изменений, внесенных в сборку.
| | Крайне важно, чтобы требования, относящиеся к пакету сборки, и зависимости сборки (от сторонних библиотек) оставались неизменными во время этого процесса. В случае изменений следует перезапустить процесс развертывания. |
3. Окончательное развертывание сборки в производственной среде - окончательное развертывание на производственном сервере, которое проходит тщательную и всестороннюю проверку коллективом PTC. Эта проверка позволяет убедиться, что все аспекты сборки соответствуют самым высоким стандартам качества, функциональности и соответствия требованиям, прежде чем она будет выпущена в производственную среду. Для проверки необходимы следующие артефакты.
◦ Заполненная анкета - подробная анкета, заполненная клиентом.
◦ Пакет сборки - ZIP-пакет, отправленный клиентами и/или системными интеграторами.
◦ Подробная документация - исчерпывающая документация по всем изменениям, внесенным в сборку на этапе подготовки. Дополнительные сведения см. в разделе "Создание полной документации: основные рекомендации".
| | Этот этап должен быть утвержден коллективом PTC. |
Рекомендации для клиентов
• Согласованность требований - начальная сборка, которую вы выгружаете, должна содержать все значимое содержимое. Крайне важно, чтобы системный интегратор избегал внесения значительных изменений в требования или зависимости (особенно от сторонних библиотек) на двух этапах развертывания - первом и третьем.
• Подробная документация - необходимо вести исчерпывающее документирование всех изменений, внесенных в сборку.
• Проверка коллективом PTC - коллектив PTC проверяет все изменения, прежде чем сборка будет продвинута для окончательного развертывания в производственной среде.
Соблюдение этих рекомендаций обеспечивает безопасный и стабильный процесс развертывания для сборки Windchill Navigate.
Как часто нужно повторять процесс развертывания?
Когда рассматривается вопрос о настройке, у вас имеется представление о конкретном варианте использования и коллективе разработчиков, работающем в циклах спринта. Ваш коллектив выбирает вариант использования, который может состоять из одного требования или их набора, и начинает его разработку в циклах спринта. Иногда для подготовки сборки может потребоваться несколько циклов спринта.
Например, в шестимесячном цикле выпуска с пятью спринтами требования выбираются и разрабатываются в рамках этих спринтов. Возможны разные временные рамки, например 20-дневные спринты с фазами разработки, контроля качества и развертывания. Если требования значительно изменяются во время цикла, процесс должен быть перезапущен и потребуется утверждение.
Частота процесса развертывания зависит от числа вариантов использования и циклов спринта. Например, при разработке 10 вариантов использования в 10 циклах спринта этот процесс повторится 10 раз. При разработке 5 вариантов использования в одном цикле спринта этот процесс повторится дважды.
Дополнительные примеры
1. Пример 1. Укороченные циклы спринта
◦ Рассматривается 2-недельный цикл спринта. Вы выбираете требование, разрабатываете его 10 дней, тратите 2 дня на контроль качества, а затем развертываете. При наличии 6 требований вы повторите этот процесс 6 раз в течение 12 недель.
2. Пример 2. Перекрывающиеся требования
◦ Имеются перекрывающиеся требования, которые охватывают выполнение нескольких спринтов. Например, требование, для выполнения которого требуется 3 спринта, будет повторяться один раз для каждого спринта, обеспечивая непрерывную интеграцию и тестирование.
3. Пример 3. Основные изменения в середине цикла
◦ Если в середине цикла в требование вносятся существенные изменения, например смена модели данных, процесс необходимо перезапустить. Это обеспечит повторную оценку всех зависимостей и получение всех утверждений.
4. Пример 4. Частые развертывания
◦ Вы предпочитаете выполнять частые развертывания и располагаете циклом спринта протяженностью в 1 неделю. Разработка занимает 4 дня, контроль качества - 1 день, на развертывание остается последний день. При наличии 8 требований вы выполняете этот процесс 8 раз в течение 8 недель.
5. Пример 5. Пользовательские временные шкалы
◦ Вы задаете пользовательские временные шкалы в соответствии с потребностями проекта. Например, имеется 30-дневный цикл спринта, из которых 20 дней уходит на разработку, 5 дней - на контроль качества и 5 дней - на развертывание. Частота процесса корректируется в зависимости от числа требований и их сложности.
Какая информация включается в анкету?
В процессе развертывания необходимо заполнить две анкеты.
1. Анкета начального развертывания - эта анкета требуется для первого развертывания в среде более низкого уровня. С ее помощью обеспечивается выполнение всех предварительных проверок и конфигураций перед продолжением работы.
2. Анкета заключительного развертывания - эта анкета требуется для заключительного развертывания в производственной среде. Она позволяет проверить, что все критические аспекты рассмотрены и утверждены, обеспечивая бесперебойное и успешное развертывание.
Пример анкеты приведен ниже.
Вопрос | Ответ | |
|---|---|---|
Общие сведения | Имя учетной записи клиента | |
Версия Windchill | ||
Версия Windchill Navigate | ||
Запланированная дата развертывания | ||
Запланированная среда развертывания | ||
Сведения о пакете | Тестировали ли вы этот пакет в средах более низкого уровня? (Если да, введите наименование среды.) | |
Какой тип настроек был реализован? | ||
Используются ли в этом пакете сторонние библиотеки? | ||
Используете ли вы метод аутентификации по умолчанию или этот пакет использует ключи приложения? | ||
Какова бизнес-модель или цель, на достижение которой рассчитана эта настройка? | ||
Уверены ли вы, что никакая часть настройки не нарушает ограничения? | ||
В чем разница между старым пакетом и новым (при их наличии)? |
| | В этой анкете нужно описать любые различия между старым и новым пакетами. Например, можно пояснить, если добавлены новые функции, исправлены ошибки или изменен номер версии. Эти различия важны, поскольку они помогают гарантировать, что все участники процесса развертывания поймут, что изменилось. Это поможет предотвратить возникновение проблем, обеспечить совместимость и убедиться, что новый пакет соответствует всем требованиям. |
Создание полной документации: основные рекомендации
При отправке заключительной сборки для развертывания в производственной среде очень важно включить в нее исчерпывающую документацию обо всех изменениях, внесенных на этапе подготовки. В этой документации должны быть подробно описаны все обновления, добавления функциональных элементов, исправления ошибок и ревизии, которые появлялись в процессе разработки.
Предоставление подробной документации обеспечивает осведомленность всех заинтересованных лиц об изменениях, что помогает устранять ошибки, поддерживать согласованность и проверять соответствие сборки всем требованиям. Этот шаг важен для бесперебойного и успешного развертывания, сводит к минимуму риск ошибок и обеспечивает полноценную подготовку производственной среды к новой сборке.
Рассмотрим следующий сценарий.
Обычно цикл компоновки начинают с версии 1.0. При создании новой версии сборки на последующих этапах ее можно обновить до версий 1.1, 1.2 и т. д. К тому времени, когда сборка будет готова к развертыванию на рабочем сервере, она может быть изменена несколько раз, чтобы достичь окончательной версии, например 1.7.
Необходимо вести подробную запись изменений, внесенных во время каждой ревизии. Например, если вы изменяете 5 элементов, четко документируйте эти изменения. Эта документация может быть представлена в виде заметок о выпуске, размер которых может различаться в зависимости от изделия.
Например, документация может включать следующие сведения.
• Версия 1.4.6. Добавлено исправление для обработки конкретной проблемы.
• Версия 1.4.5. Реализована новая функция.
• Версия 1.4.4. Повышена производительность для отдельной функции.
Этот тип документации помогает отслеживать процесс сборки от версии 1.0 до версии 1.7. Вы можете использовать скриншоты или любой формат, который наилучшим образом передает соответствующую информацию. Ключевым моментом является обеспечение всестороннего отслеживания изменений. Вам необходимо создать формат в соответствии со своими потребностями, например: документ Word, лист Excel или любой другой документ.
Ниже приведены примеры журналов изменений.
Пример 1. "Краткий журнал изменений" - однострочная сводка для краткой справки
Пример 2. "Подробный журнал изменений" - полный список обновлений
Пример 3. "Полный журнал изменений" - полная подборка обновлений, исправлений и улучшений
