Непрерывная интеграция - снижение рисков

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

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

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

Риск 1 - Отсутствие развертываемого программного обеспечения

“It works on my machine but does not work on another”- Вероятно, это одна из самых распространенных фраз, встречающихся в любой программной организации. Из-за количества изменений, вносимых в сборки программного обеспечения ежедневно, иногда нет уверенности в том, действительно ли сборка программного обеспечения работает или нет. Эта проблема имеет следующие три побочных эффекта.

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

Решение

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

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

“Inability to synchronize with the database”- Иногда разработчики не могут быстро воссоздать базу данных во время разработки, и поэтому им сложно вносить изменения. Часто это происходит из-за разделения между командой базы данных и командой разработчиков. Каждая команда будет сосредоточена на своих обязанностях и будет мало сотрудничать друг с другом. Эта проблема имеет следующие три побочных эффекта:

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

Решение

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

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

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

Риск 2 - обнаружение дефектов на поздних этапах жизненного цикла

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

Решение

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

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

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

Риск 3 - Недостаточная прозрачность проекта

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

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

Решение

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

Риск 4 - Программное обеспечение низкого качества

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

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

Решение

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