Быстрое изменение приложений с помощью Rational Team Concert

Источник: ibm

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

Введение

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

Использование этих вариантов позволяет ускорить коллективные изменения приложений. Начните со сравнения вариантов модернизации приложения. Определите вариант с наилучшей окупаемостью инвестиций. Создайте план с помощью IBM® Rational Team Concert™. После создания плана определите членов группы для работы с Rational Team Concert. На последнем шаге создайте политики пороговых значений, соответствующие вашим требованиям.

Шаг 1. Сравнение вариантов модернизации приложения

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

Размещение приложения на другой платформе.
Миграция приложения на систему управления базами данных.
Разделение на более мелкие компоненты.

Размещение приложения на другой платформе

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

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

Миграция приложения на систему управления базами данных

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

Нормализация базы данных путем организации таблиц для минимизации избыточности и зависимости данных позволяет:

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

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

Разделение большого приложения на более мелкие компоненты

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

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

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

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

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

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

Шаг 2. Создание плана с помощью Rational Team Concert

Для создания плана изменений приложения с помощью Rational Team Concert требуется совместная работа пользователей, разработчиков, специалистов по эксплуатации и ИТ-менеджеров. Rational Team Concert, входящий в состав решения Rational® Collaborative Lifecycle Management, можно использовать для работы с IBM® Rational® Requirements Composer.

Rational Team Concert позволяет всем членам группы участвовать в создании плана.

Пользователи могут обращаться к специалистам по эксплуатации напрямую (минуя разработчиков) для определения проблем эксплуатации приложения.
Разработчики могут обращаться к пользователям по поводу готовности списка требований или необходимости изменений, соответствующих ожиданиям пользователей.
Специалисты по эксплуатации и ИТ-менеджеры могут напрямую обращаться к разработчикам, чтобы узнать, почему приложение работает нестабильно или что является причиной частых пиковых ситуаций в производственной среде.

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

Ожидания пользователей

Пользователи ожидают включения в план Rational Team Concert следующих требований к приложению:

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

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

Ожидания разработчиков

План Rational Team Concert должен отвечать следующим задачам:

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

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

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

Функциональные требования: Изменения поведения приложения.
Нефункциональные (качество сервиса) требования: Изменения условий, не затрагивающие эффективность приложения.
Реализация требований в зависимости от платформы: Изменения требований, связанные с работой приложения на другой платформе. Эти требования определяют изменения, необходимые для обеспечения нормальной работы приложения в новой среде, например на облачной платформе.
Бизнес-требования: Изменение целей и задач приложения, а также требований организации к нему.
Требования пользователей: Изменения требований заинтересованных сторон к взаимодействию с разрабатываемым приложением.

Ожидания специалистов по эксплуатации и ИТ-менеджеров

Специалисты по эксплуатации и ИТ-менеджеры ожидают, что план будет охватывать следующие требования:

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

Специалисты по эксплуатации и ИТ-менеджеры должны сотрудничать с разработчиками для обеспечения нормальной работы приложения в производственной облачной среде.

Шаг 3. Определения участников Rational Team Concert

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

Владелец продукта: Принимает окончательные решения касательно изменения требований и пороговых значений масштабируемости. Владелец продукта отвечает за окупаемость инвестиций и прибыль.
Скрам-мастер: Проводит скрам-совещания, но не является руководителем проекта. Скрам-мастер и скрам-команда используют представление Rational Team Concert Taskboard (резерв спринта), которое служит перечнем задач для скрам-мастера. В этом представлении отображается состояние задач (не начата, выполняется, завершена). В нем также отображается решение проблем.
Группа разработки приложения: Это межфункциональная группа, которая пытается нарастить функциональность в каждом спринте. Ее члены взаимодействуют друг с другом с помощью представления My Work в среде разработки в Rational Team Concert. Членами могут быть рассредоточенные по всему миру разработчики, взаимодействующие с помощью Rational Team Concert, и пользователи приложения в облачной среде.
Заинтересованные стороны: Это руководители высшего звена. С помощью панелей Rational Team Concert заинтересованные стороны могут следить за ходом проекта. Чтобы получить более подробное описание, они могут использовать панели трех видов: владельца продукта, скрам-мастера и члена группы разработки.

Членами группы DevOps являются:

Планировщики бизнеса: Обеспечивают непрерывное бизнес-планирование, помогая компании начать с небольшого плана и развивать его путем постоянного обновления.
Разработчики и тестировщики: Взаимодействуют и обмениваются информацией со специалистами по эксплуатации и ИТ-менеджерами по вопросам непрерывной разработки и тестирования. Разработчики и тестировщики стремятся реализовать ожидания пользователей. Разработчики имеют доступ к Rational Team Concert на протяжении всего жизненного цикла приложения, включая этап тестирования. Бизнес-подразделения, группы разработки и обеспечения качества сотрудничают друг с другом. Для уменьшения стоимости тестирования можно использовать процедуры автоматического тестирования.

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

К пользователям приложения в облачной среде относятся:

Конечные пользователи приложения: Это физические лица, компании (мелкие и средние) и правительственные учреждения. Эти пользователи работают с приложением только в облачной среде.
Распределенные по всему миру разработчики, использующие для создания приложений платформу разработки, например Rational Team Concert: Они осуществляют контроль и защиту приложений, являющихся частью полного жизненного цикла бизнеса. Разработчик может входить в состав скрам-группы, занимающейся, например, созданием и тестированием приложения для управления прибытием/отправлением. В качестве члена скрам-группы разработчик взаимодействует и обменивается информацией со специалистами по эксплуатации и ИТ-менеджерами.

Шаг 4. Создание политик пороговых значений масштабирования

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

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

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

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

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

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

Заключение

Изменение поведения приложения требует предварительного планирования для решения проблем и использования принципов DevOps и гибкой разработки с помощью Rational Team Concert. До начала планирования изменений приложения проанализируйте ожидания пользователей, разработчиков, специалистов по эксплуатации и ИТ-менеджеров. С помощью Rational Team Concert и принципов DevOps можно ускорить изменения, повысить масштабируемость приложения и сделать совместную работу членов группы более эффективной. Можно также создать политики пороговых значений для изменений требований. Кроме того, можно выбрать наиболее подходящую платформу. Новички в Rational Team Concert могут использовать версию Rational Team Concert на Jazz.net, предназначенную специально для разработчиков.