Для установки нажмите кнопочку Установить расширение. И это всё.

Исходный код расширения WIKI 2 регулярно проверяется специалистами Mozilla Foundation, Google и Apple. Вы также можете это сделать в любой момент.

4,5
Келли Слэйтон
Мои поздравления с отличным проектом... что за великолепная идея!
Александр Григорьевский
Я использую WIKI 2 каждый день
и почти забыл как выглядит оригинальная Википедия.
Статистика
На русском, статей
Улучшено за 24 ч.
Добавлено за 24 ч.
Что мы делаем. Каждая страница проходит через несколько сотен совершенствующих техник. Совершенно та же Википедия. Только лучше.
.
Лео
Ньютон
Яркие
Мягкие

Непрерывная интеграция

Из Википедии — свободной энциклопедии

Разработка программного обеспечения
Ключевые процессы
Парадигмы и модели
Методологии
Инструменты

Непрерывная интеграция (CI, англ. Continuous Integration) — практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счёт наиболее раннего обнаружения и устранения ошибок и противоречий, но основным преимуществом является сокращение стоимости исправления дефекта, за счёт раннего его выявления.

Впервые концептуализирована и предложена Гради Бучем в 1991 году[1]. Является одним из основных элементов практики экстремального программирования.

Организация

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

Для организации процесса непрерывной интеграции на выделенном сервере запускается служба, в задачи которой входят:

  • получение исходного кода из репозитория;
  • сборка проекта;
  • выполнение тестов;
  • развёртывание готового проекта;
  • отправка отчетов.

Локальная сборка может осуществляться по внешнему запросу, по расписанию, по факту обновления репозитория и по другим критериям.

Сборки по расписанию (англ. daily build — ежедневная сборка), как правило, проводятся в нерабочее время, ночью (англ. nightly build), планируются таким образом, чтобы к началу очередного рабочего дня были готовы результаты тестирования. Для различия дополнительно вводится система нумерации сборок — обычно, каждая сборка нумеруется натуральным числом, которое увеличивается с каждой новой сборкой. Исходные тексты и другие исходные данные при взятии их из репозитория (хранилища) системы контроля версий помечаются номером сборки. Благодаря этому, точно такая же сборка может быть точно воспроизведена в будущем — достаточно взять исходные данные по нужной метке и запустить процесс снова. Это даёт возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями.

Преимущества и недостатки

К преимуществам непрерывной интеграции относятся следующие моменты:

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

При этом, практика не лишена недостатков, в частности:

  • значительные затраты на поддержку работы непрерывной интеграции;
  • необходимость в дополнительных вычислительных ресурсах под нужды непрерывной интеграции;

Кроме того, немедленный эффект от неполного или неработающего кода отучает разработчиков от выполнения периодических резервных включений кода в репозиторий, но в случае использования системы управления версиями исходного кода с поддержкой ветвления, эта проблема может решаться созданием отдельной «ветки» (англ. branch) проекта для внесения крупных изменений (код, разработка которого до работоспособного варианта займет несколько дней, но желательно более частое сохранение результата в репозиторий). По окончании разработки и индивидуального тестирования такой ветки, она может быть объединена (merge) с основным кодом или «стволом» (trunk) проекта.

Примечания

  1. Booch, Grady. Object Oriented Design: With Applications (англ.). — Benjamin Cummings  (англ.), 1991. — P. 209. — ISBN 9780805300918.

Литература

  • Поль М. Дюваль, Стивен М. Матиас III, Эндрю Гловер. Непрерывная интеграция: улучшение качества программного обеспечения и снижение риска = Continuous Integration: Improving Software Quality and Reducing Risk (The Addison-Wesley Signature Series). — Вильямс, 2008. — 2000 экз. — ISBN 978-5-8459-1408-8, 0-321-33638-0.

Ссылки

Эта страница в последний раз была отредактирована 4 марта 2023 в 00:31.
Как только страница обновилась в Википедии она обновляется в Вики 2.
Обычно почти сразу, изредка в течении часа.
Основа этой страницы находится в Википедии. Текст доступен по лицензии CC BY-SA 3.0 Unported License. Нетекстовые медиаданные доступны под собственными лицензиями. Wikipedia® — зарегистрированный товарный знак организации Wikimedia Foundation, Inc. WIKI 2 является независимой компанией и не аффилирована с Фондом Викимедиа (Wikimedia Foundation).