Переход от «каскадной» к «гибкой» методике разработки информационных систем

За последние годы во многих организациях начала вырабатываться ритмичность поставки обновлений информационных систем (далее ИС). Формируется прогрессивная культура ежемесячных или еженедельных «спринтов». В этом большая заслуга девопс разработчиков и администраторов ИС.

Подобный ритм поставки обновлений ИС соответствует «гибким» методикам разработки [1]. Для использования «гибких» методик требуется использовать технологии непрерывной доставки и интеграции (англ. Continuous delivery и Continuous integration, CI/CD [2]) и микросервисную архитектуру ИС.

Не погружаясь в детали реализации технологии CI/CD можно заметить ее важную особенность — это потребность в покрытии всей разрабатываемой ИС автоматизированными тестами. Эти тесты позволяют заблаговременно выявлять и исправлять ошибки. Для создания тестов требуется технологическая база, а также покрытие всей ИС и ее инфраструктуры отслеживанием метрик. Без этих метрик и автоматизированных тестов администраторы и взаимоотношениями ИС в авральном режиме вынуждены исправлять неизбежные ошибки после каждого обновления. Перед внедрением гибких методик это надо исправлять.

Для начала надо сформировать метрики ИС и обеспечить их отслеживание через систему дашбордов. Протестировать их можно локально в Microsoft Power BI [3], в облаке или на корпоративном сервере в Yandex DataLens [4]. Далее можно покрыть автоматизированными тестами ключевые элементы ИС, а затем и всю ИС. После можно обеспечить непрерывность доставки и интеграции обновлений ИС. Важно заметить, что во многих современных ИС уже есть для этого все необходимое.

В целях гибкой разработки помимо CI/CD также важно управление версиями разрабатываемой ИС. Управление версиями позволяет оперативно «откатываться» до предыдущих версий в случае появления критических ошибок в ИС. Также управление версиями позволяет разветвлять процесс разработки. Пока одни разработчики создают один микросервис, другие разработчики могут заниматься другим микросервисом. Затем обе ветки разработки можно объединить в единый релиз. При использовании технологий управления версиями, как и для CI/CD, важно покрытие тестами всей разрабатываемой ИС, а также наличие метрик и систем для их контроля. Чем сложнее и разветвленней процесс разработки, тем выше потребность в автоматических тестах и отслеживания метрик.

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

Список используемых источников:

информационная система информация корпоративная информационная система