Есть вероятность, что в проекте что-то пойдет не так. Эффективно практикуя CI, вы узнаете, что происходит на каждом этапе пути, а не позже, когда проект входит в цикл разработки. CI помогает вам выявлять и смягчать риски, когда они возникают, облегчая оценку и составление отчетов о состоянии проекта на основе конкретных данных.
Этот раздел посвящен рискам, которых можно избежать с помощью непрерывной интеграции.
В любом проекте существует множество рисков, которыми необходимо управлять. Устраняя риски на ранних этапах жизненного цикла разработки, существует меньшая вероятность того, что эти риски перерастут в проблемы, которые возникнут позднее, когда система фактически заработает.
Риск 1 — отсутствие развертываемого программного обеспечения
«Он работает на моем компьютере, но не работает на другом» — это, вероятно, одна из самых распространенных фраз, встречающихся в любой организации программного обеспечения. Из-за количества изменений, вносимых в сборки программного обеспечения на ежедневной основе, иногда мало уверенности в том, работает ли сборка программного обеспечения на самом деле или нет. Эта проблема имеет следующие три побочных эффекта.
-
Мало или нет уверенности в том, сможем ли мы даже создать программное обеспечение.
-
Длительные этапы интеграции перед поставкой программного обеспечения внутренне (т. Е. Группой тестирования) или извне (т. Е. Клиентом), в течение которого больше ничего не делается.
-
Невозможность производить и воспроизводить тестируемые сборки.
Мало или нет уверенности в том, сможем ли мы даже создать программное обеспечение.
Длительные этапы интеграции перед поставкой программного обеспечения внутренне (т. Е. Группой тестирования) или извне (т. Е. Клиентом), в течение которого больше ничего не делается.
Невозможность производить и воспроизводить тестируемые сборки.
Решение
Устранение тесной связи между IDE и процессами сборки. Используйте отдельную машину исключительно для интеграции программного обеспечения. Убедитесь, что все необходимое для сборки программного обеспечения содержится в репозитории контроля версий. Наконец, создайте систему непрерывной интеграции.
Сервер Continuous Integration может наблюдать за изменениями в хранилище управления версиями и запускать сценарий сборки проекта, когда обнаруживает изменение в хранилище. Возможности системы непрерывной интеграции можно расширить, включив в нее выполнение сборки с помощью тестов, проверок и развертывания программного обеспечения в средах разработки и тестирования; Таким образом, у вас всегда есть работающее программное обеспечение.
«Невозможность синхронизации с базой данных». Иногда разработчики не могут быстро воссоздать базу данных во время разработки, и, следовательно, им трудно вносить изменения. Часто это происходит из-за разделения между командой разработчиков базы данных и командой разработчиков. Каждая команда будет сосредоточена на своих собственных обязанностях и будет мало сотрудничать друг с другом. Эта проблема имеет следующие три побочных эффекта —
-
Страх внесения изменений или рефакторинга базы данных или исходного кода.
-
Сложность в заполнении базы данных различными наборами тестовых данных.
-
Трудности в поддержке сред разработки и тестирования (например, Разработка, Интеграция, Контроль качества и Тестирование).
Страх внесения изменений или рефакторинга базы данных или исходного кода.
Сложность в заполнении базы данных различными наборами тестовых данных.
Трудности в поддержке сред разработки и тестирования (например, Разработка, Интеграция, Контроль качества и Тестирование).
Решение
Решение вышеупомянутой проблемы состоит в том, чтобы обеспечить размещение всех артефактов базы данных в репозитории контроля версий. Это означает все, что требуется для воссоздания схемы и данных базы данных: сценарии создания базы данных, сценарии манипулирования данными, хранимые процедуры, триггеры и любые другие активы базы данных.
Перестройте базу данных и данные из вашего сценария сборки, удалив и заново создав базу данных и таблицы. Затем примените хранимые процедуры и триггеры и, наконец, вставьте тестовые данные.
Протестируйте (и осмотрите) свою базу данных. Как правило, вы будете использовать тесты компонентов для проверки базы данных и данных. В некоторых случаях вам нужно будет написать тесты для конкретной базы данных.
Риск 2 — обнаружение дефектов в конце жизненного цикла
Поскольку в исходном коде часто происходит множество изменений, которые часто происходят у многих разработчиков, всегда есть вероятность того, что в коде может быть обнаружен дефект, который может быть обнаружен только на более позднем этапе. В таких случаях это может оказать большое влияние, поскольку чем позже дефект обнаружен в программном обеспечении, тем дороже становится его устранение.
Решение
Регрессионное тестирование — это самый важный аспект любого цикла разработки программного обеспечения, тестируйте и тестируйте снова. В случае каких-либо существенных изменений в программном коде, абсолютно необходимо убедиться, что все тесты запущены. И это может быть автоматизировано с помощью сервера непрерывной интеграции.
Охват тестами. Нет смысла тестировать, если тестовые примеры не охватывают всю функциональность кода. Важно убедиться, что контрольные примеры, созданные для тестирования приложения, выполнены и все пути кода проверены.
Например, если у вас есть экран входа в систему, который необходимо протестировать, у вас просто не может быть тестового случая, в котором есть сценарий успешного входа в систему. Вам нужен отрицательный тестовый пример, в котором пользователь вводит другую комбинацию имен пользователей и паролей, а затем необходимо посмотреть, что происходит в таких сценариях.
Риск 3 — Отсутствие видимости проекта
Механизмы ручного взаимодействия требуют большой координации, чтобы обеспечить своевременное распространение информации о проекте нужным людям. Обращаться к разработчикам рядом с вами и сообщать им, что последняя сборка находится на общем диске, довольно эффективно, но не очень хорошо масштабируется.
Что, если есть другие разработчики, которым нужна эта информация, и они на перерыве или иным образом недоступны? Если сервер выходит из строя, как вы получаете уведомление? Некоторые считают, что они могут уменьшить этот риск, отправив электронное письмо вручную. Однако это не может гарантировать, что информация будет передана нужным людям в нужное время, поскольку вы можете случайно пропустить заинтересованные стороны, а некоторые могут не иметь доступа к их электронной почте в данный момент.
Решение
Решением этой проблемы снова является сервер непрерывной интеграции. Все серверы CI имеют возможность иметь автоматическую электронную почту, которая запускается при сбое сборки. Посредством этого автоматического уведомления всем ключевым заинтересованным сторонам также гарантируется, что все будут в курсе текущего состояния программного обеспечения.
Риск 4 — Низкое качество программного обеспечения
Есть дефекты, а затем есть потенциальные дефекты. У вас могут быть потенциальные дефекты, если ваше программное обеспечение не разработано должным образом, если оно не соответствует стандартам проекта или является сложным в обслуживании. Иногда люди называют это запахом кода или дизайна — «признаком того, что что-то может быть не так».
Некоторые считают, что низкокачественное программное обеспечение — это только отложенная стоимость проекта (после поставки). Это может быть отложенная стоимость проекта, но это также приводит ко многим другим проблемам, прежде чем вы доставите программное обеспечение пользователям. Чрезмерно сложный код, код, который не соответствует архитектуре, и дублированный код — все это обычно приводит к дефектам в программном обеспечении. Обнаружение этих запахов кода и дизайна до того, как они превратятся в дефекты, может сэкономить как время, так и деньги, и может привести к повышению качества программного обеспечения.
Решение
Существуют программные компоненты для проверки качества кода, которые можно интегрировать с программным обеспечением CI. Это может быть выполнено после того, как код собран, чтобы гарантировать, что код фактически соответствует надлежащим правилам кодирования.