Ежедневные сборки и непрерывная интеграция в разработке ПО
Daily build
Ежедневная сборка (daily build) в разработке ПО: что это, зачем нужна, преимущества для больших команд. Проверка зависимостей, тестирование, обратная связь.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Ежедневная сборка или ночная сборка – это практика ежедневного создания сборки программного обеспечения последней версии программы. Это делается для того, чтобы сначала скомпилировать её и убедиться в наличии всех необходимых зависимостей, а также, возможно, провести тестирование для выявления новых ошибок. Ежедневная сборка часто бывает общедоступной, предоставляя доступ к новейшим функциям для получения обратной связи. В данном контексте сборка – это результат компиляции и компоновки всех файлов, составляющих программу. Использование таких дисциплинированных процедур, как ежедневные сборки, особенно важно в крупных организациях, где над одним программным обеспечением работает множество программистов. Выполнение ежедневных сборок помогает разработчикам работать с уверенностью в том, что любые новые обнаруженные ошибки, скорее всего, связаны с их изменениями, внесенными за последний день. Ежедневные сборки обычно включают в себя набор тестов, иногда называемый "дымовым тестированием". Эти тесты предназначены для определения, какие компоненты могли быть нарушены изменениями, включенными в последнюю сборку. Ключевым аспектом этого процесса является добавление новых и обновленных тестов по мере развития проекта.
A daily build or nightly build is the practice of completing a software build of the latest version of a program, on a daily basis. This is so it can first be compiled to ensure that all required dependencies are present, and possibly tested to show no bugs have been introduced. The daily build is also often publicly available allowing access to the latest features for feedback. In this context, a build is the result of compiling and linking all the files that make up a program. The use of such disciplined procedures as daily builds is particularly necessary in large organizations where many programmers are working on a single piece of software. Performing daily builds helps ensure that developers can work knowing with reasonable certainty that any new bugs that show up are a result of their own work done within the last day. Daily builds typically include a set of tests, sometimes called a "smoke test." These tests are included to assist in determining what may have been broken by the changes included in the latest build. The critical piece of this process is to include new and revised tests as the project progresses.
Постоянная интеграция
Хотя ежедневные сборки считались передовой практикой разработки программного обеспечения в 1990-х годах, они устарели. Сейчас непрерывная интеграция выполняется практически постоянно, с типичным временем цикла около 20-30 минут с момента последнего изменения исходного кода. Серверы непрерывной интеграции непрерывно отслеживают систему контроля версий. При обнаружении новых изменений эти серверы используют инструмент сборки для перекомпиляции программного обеспечения. Современной передовой практикой также является использование непрерывной интеграции в сочетании с непрерывным тестированием, чтобы модульные тесты запускались повторно для каждой сборки, а более масштабное функциональное тестирование (которое занимает больше времени, чем сборка) выполнялось как можно чаще, в зависимости от его длительности.
Although daily builds were considered a best practice of software development in the 1990s, they have now been superseded. Continuous integration is now run on an almost continual basis, with a typical cycle time of around 20 30 minutes since the last change to the source code. Continuous integration servers continually monitor the source code control system. When these servers detect new changes, they use a build tool to rebuild the software. Good practice today is also to use continuous integration as part of continuous testing, so that unit tests are re run for each build, and more extensive functional testing (which takes longer to perform than the build) performed as frequently as its duration permits.