Ночная сборка что это
Ночные сборки
Ночные сборки
Ночные сборки — промежуточные рабочие сборки програмного обеспечения. Собираются автоматически ежедневно из последней версии исходного кода в репозитории. Данный вид сборок обычно является нестабильным и используется только разработчиками. Ночные сборки содержат префикс «N» + дата + номер.
Смотреть что такое «Ночные сборки» в других словарях:
Автоматизация сборки (разработка ПО) — Автоматизация сборки этап написания скриптов или автоматизация широкого спектра задач применительно к ПО, применяемому разработчиками в их повседневной деятельности, включая такие действия, как: Компиляция исходного кода в бинарный код… … Википедия
Автоматизация сборки — Для улучшения этой статьи желательно?: Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное. Переработать оформление в соответствии с правилами написания статей … Википедия
Acid2 — У этого термина существуют и другие значения, см. Acid. Так должен выглядеть правильно обработанный тест Acid2 тестовая страница, предназначенная для проверки веб браузеров на соответствие некоторым веб стандартам. Acid2 … … Википедия
Непрерывная интеграция — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
JMule — Тип Клиент для файлообменных сетей Разработчик JMule Team Написана на Java Последняя версия 0.5.6 (7 января 2010) Лицензия GNU General Public … Википедия
SeaMonkey — SeaMonkey … Википедия
ffdshow — ffdshow … Википедия
KolibriOS — У этого термина существуют и другие значения, см. Колибри (значения). KolibriOS … Википедия
Кодовое имя — Кодовое имя, коднэйм (англ. code name, cryptonym) слово или словосочетание, непосредственно привязанное (например, разработчиком) к другому слову или словосочетанию (например, торговой марке). Часто используются военными, шпионами в… … Википедия
Сборка — В Викисловаре есть статья «сборка» Сборка (действие): Сборка (техника) образование соединений составных частей изделия (по ЕСТД … Википедия
Что означает «Ночные сборки»?
Я использовал проекты с открытым исходным кодом некоторое время и разрабатывал приложения с открытым исходным кодом, и время от времени я сталкивался со словами «Ночная сборка», и мне всегда было любопытно, что это на самом деле означает. Означает ли это буквально, что проекты выполняются исключительно как побочные проекты (обычно ночью, после того, как все закончили свои дневные работы), и нет никакого реального участника / специальной группы разработчиков, или это более сложно?
Нет, это означает, что каждую ночь создается все, что было проверено в системе контроля версий. Эта сборка является «ночной сборкой».
Обычно это означает автоматическую сборку, которая выполняется один раз в день, как правило, после окончания дня для большинства разработчиков. Для проектов с разработчиками в нескольких часовых поясах это обычно компромиссное время. Идея состоит в том, что каждый, кто собирается проверить код «сегодня», сделал это, и автоматическая сборка убедится, что все скомпилировано, и, мы надеемся, запустим модульные тесты и любые другие существующие автоматические тесты и т. Д., А затем создаст окончательный установщик. / исполняемый и т. д.
Это означает, что сборка выполняется в конце каждого дня разработки. Если вы используете сервер непрерывной интеграции, он, как правило, будет настроен для построения кода и запуска модульных тестов при каждой регистрации. В конце каждого дня вы можете запускать более масштабные тесты, например, регрессионные и интеграционные тесты: которые занимают слишком много времени при каждой регистрации, и они будут срабатывать после ночной сборки. Если у вас есть полный непрерывный конвейер доставки, ночная сборка может также использоваться для развертывания встроенного кода в средах для пользовательского тестирования.
Этот термин часто используется для крупных проектов, где полная переработка готового продукта из исходного кода занимает слишком много времени для отдельного разработчика, чтобы сделать это как часть их обычного цикла разработки.
Вместо этого полная перестройка выполняется автоматически в течение ночи, поэтому сборочный компьютер имеет 8-10-12 часов для сборки и готовит ее для разработчиков, приходящих на следующее утро, чтобы они могли продолжить работу над своим крошечным кусочком сверху. новой версии.
В наши дни проект часто включает в себя множество тестов, обеспечивающих правильную работу кода, а также генерирует и публикует документацию из исходного кода (например, javadoc).
Автотесты, ночные сборки, экстремальный Agile. Как мы тестируем наши продукты
Наше тестирование — большой продукт, сжатые сроки, огромная ответственность.
В каждой компании свои взгляды на организацию рабочих процессов. И они могут сильно отличаться.
Сегодня мы хотим рассказать о том, как мы тестируем наши продукты. Возможно, с чем-то вы поспорите, а что-то возьмёте на вооружение.
Наши продукты состоят из десятков модулей. Мы регулярно обновляем их, и эти апгрейды — завершенные мини-продукты.
Разработчики, собирают пачку кода в отдельную версию. И пишут описание: «Новый интернет-магазин в облаке. Изменения такие-то. Добавили кучу новых страниц». И обязательно прикладывают огромный changelog с несколькими сотнями коммитов.
Всё это поступает к тестировщикам. Этот процесс я называю «экстремальным Agile» — мы работаем по чётким итерациям. Отклоняться от этих правил тестирования нельзя.
Это необходимая мера — продукт огромен, как и изменения в нём. И чтобы не затягивать тестирование, мы жертвуем определённой свободой.
Получив задание на проверку обновления, мы сверяемся с планом тестирования. Он разработан отдельно под каждый модуль. В плане перечислены все важные сценарии использования.
Раньше мы делали так. Составляли подробные описания прецедентов: «Нажимаем сюда. В поле ввода пароля должны появиться кружочки. Если они не появляются, что-то не так».
От этой практики мы отказались, когда количество прецедентов превысило все разумные пределы.
В результате мы пришли к тому, что наш план тестирования — это перечисление важных бизнес-сценариев.
Пример — список кейсов по работе с задачами в «Битрикс24».
— Сохранение задачи работает? Отлично, идём дальше.
— Комментарии к задаче добавляются? Прекрасно, следующий пункт.
Сначала мы начинаем с верхнеуровневых, главных сценариев — например, создание и сохранение заказа магазина. А потом переходим к сценариям уровнем ниже — например, корректная работа крайнего срока в задачах.
Дальше мы за несколько этапов проверяем, как выполняются системные действия.
Этапы тестирования
В самом начале мы запускаем автотесты для конкретных модулей. Мы прогоняем через них все прибыльные модули.
Параллельно с прогоном автотестов мы делаем:
1 этап
— Изучаем описание изменений от разработчиков.
Смотрим, как должно быть по ТЗ. Сравниваем с тем, как модуль сделан в реальности. Но главное — учимся смотреть на продукт и изменения с точки зрения здравого смысла и обычного пользователя.
Удобен ли рабочий сценарий? Всё сделано «по-человечески»? Параллельно проводим ещё и usability-тестирование.
Это не всегда получается — изменений огромное количество. Но мы всё равно подсказываем разработчикам, когда какой-то сценарий можно сделать удобнее.
Мы автоматизировали огромную часть рутины. И постоянно думаем что можно «докрутить».
Вопросы к разработчикам мы обсуждаем в отдельных чатах под каждое обновление. У нас нет «сломанного телефона» — в чате присутствуют все сотрудники, причастные к выпуску.
2 этап
Итак, мы изучили описание обновления, и дальше вчитываемся в лог изменений — это второй этап.
— На этом этапе мы «отлавливаем» большинство ошибок. Разработчик может что-то упустить в «обычном» описании, но changelog покажет все ошибки.
Недавно был курьёз. Разработчик внёс изменения в текст локализованной версии продукта. На французском языке.
Казалось бы, просто текст. Но в этой хитрой комбинации был апостроф. В итоге на определённом этапе тестирования у нас просто начал падать JavaScript.
Оказалось что система просто не умеет обрабатывать эту комбинацию. Но автор изменения не упомянул о нём в описании. Ошибку мы нашли только в результате внимательного изучения лога изменений.
3 этап
Затем начинается третий этап — анализ обращений клиентов по ошибкам в продукте:
Обращения регистрируются в нашей системе трекинга ошибок Mantis. Почему мы её используем? Это историческое наследие, Mantis «трудится» у нас уже лет 15.
Я несколько раз предлагал коллегам найти что-то другое. Начинали анализировать и каждый раз оказывалось, что в Mantis есть все что нам нужно. Мы отлично интегрировали её в работу: связали с «открытыми линиями» и техподдержкой.
Весь журнал обращений клиентов по поводу ошибок мы берем в Mantis.
В каждое мини-обновление у нас включаются и фичи, и исправления багов, которые нашли клиенты и тестировщики.
Разработчик утверждает, что ошибка исправлена — мы проверяем. Если ошибка не исправлена, возвращаем тикет в работу.
Если разработчик несколько раз не может исправить одну и ту же ошибку, то убираем эту неработающую часть из обновления, отправляем на доработку разработчику.
4 этап
После верификации переходим к четвертому этапу — повторному прогону тестового плана.
Ситуация на рынке может поменяться. Если вчера условия были одни, то завтра они могут измениться. У нас нет жесткой привязки к ТЗ, которое мы разработали полгода назад. Поэтому мы прогоняем тестовый план еще раз.
5 этап
Пятый этап — сборка пакета обновлений и выгрузка в эталонную среду тестирования: Она находится в облаке Amazon и представляет собой отдельный портал «Битрикс24».
Здесь проводится окончательная проверка бизнес-сценариев. Ночью прогоняется весь комплект автотестов, они отслеживают изменения в показателях инфраструктуры.
6 этап
На шестом этапе мы организуем группы закрытого тестирования.
В группах состоят не тестировщики, а реальные клиенты и наши партнеры. Мы делаем это, чтобы получить обратную связь от реальных пользователей нашего продукта. Тех, кто непосредственно будет с ним работать.
К этому этапу почти все ошибки уже выловлены. Пользователи рассказывают, насколько им удобно работать по разным сценариям. Можно назвать это дополнительyым usаbility-тестированием.
7 этап
Потом наступает очередь седьмой этап — полузакрытое тестирование:
Как правило, у себя в Facebook я приглашаю клиентов первыми протестировать наши новинки. Поучаствовать может любой желающий, это бесплатно, просто напишите мне.
Для полузакрытого тестирования у нас есть stage-среда. В нее добавляются порталы клиентов, пожелавших принять участие. Обычно мы набираем несколько тысяч порталов, но все зависит от масштабов обновления.
Здесь мы тоже оцениваем удобство работы с продуктом, удобство сценариев.
Есть вещи, которые иногда кажутся неочевидными и на предыдущем этапе партнёры пишут, что так делать нельзя. А этот этап позволяет обкатать решение на гораздо большей выборке клиентов, проверить заложенные гипотезы.
Этот этап может занимать 2-3 недели. Мы постоянно вносим изменения по фидбэкам клиентов.
После тестирования на стейдже обновление выкатывается в production. А мы радостно пишем обучающие статьи и снимаем видео.
О своих впечатлениях вы можете писать в Facebook, лично или на публичной странице. Задавайте вопросы, высказывайте мнение, критикуйте — я всегда приветствую конструктив.
Cloud first
Многие клиенты жалуются, что мы выпускаем обновления сначала для облачной версии «Битрикс24». Пока нам не удалось построить процесс тестирования и выпуск продукта так, чтобы синхронно выпускать обновления и для «облака», и для «коробки».
Выпуск коробочного обновления — более сложный процесс. Если вы знакомы с обкаткой сырого продукта, то знаете, что такое тестовая среда. В облаке у нас уже есть готовая инфраструктура с заданными версиями PHP и MySQL со своей кодировкой. Там всё настроено и работает — можно ставить продукт и спокойно тестировать.
С «коробкой» все по-другому. Вариативность «сред» у клиентов огромна. Мы стараемся стимулировать пользователей к переходу на более высокие версии PHP, но многие делают это неохотно.
По факту, немалая доля клиентов начинают менять версию PHP, только когда их заставляют хостеры. Добавьте к этому разнообразие версий MySQL и кодировок.
Вот почему тестирование «коробки» намного сложнее и дольше по времени.
Автотестирование
Выше я подробно рассказал о процессе ручного тестирования, но это лишь часть всего процесса. Не менее важную роль играет автотестирование.
Созданием автотестов у нас занимается специальный отдел.
Раньше мы писали большие сценарные проекты. И эти сценарии были связаны между собой. Но их сложно поддерживать, если за небольшое время в продукте выкатывается огромное количество изменений.
Поэтому мы разбили большие сценарные автотесты на более мелкие независимые сценарии, кейсы.
Как проходит среднестатистический автотест?
Раньше мы тестировали только через интерфейс.
Есть мнение, что чем больше мы прокликаем интерфейс, тем лучше. Но мы от этого ушли, потому что сегодня важно тестирование по прецедентам.
Smoke-тесты и ночные автотесты
Также мы проводим smoke-тесты. Они работают очень быстро и проверяют самые верхнеуровневые, самые популярные бизнес-сценарии.
Обычно мы используем их для финальной проверки.
Если мы возвращаемся к процессу большого тестирования, большой итерации, большого пакета обновлений, то «ставим» пакет на эталонную среду. И ночью по расписанию запускаются автотесты. Все спят, а робот кликает по заданным сценариям.
Сейчас наш полный цикл ночных автотестов наконец-то стал укладываться в ночное время. Раньше он занимал около 32 часов. Ускорить автотесты удалось с помощью виртуальных машин и постоянных оптимизаций фреймворка и самих тестов.
А вот чего в нашем процессе тестирования нет, так это постоянной интеграции. Она нам не подходит, потому что есть накопленное «историческое наследие».
Мы не можем отказаться от какой-то части инфраструктуры, которая очень велика и сложна. Так что мы пока робко пробуем внедрить небольшие элементы классической continuous integration.
Ночные сборки
Пользователи коробочной версии знают, что каждые три месяца мы выпускаем новый дистрибутив. И на протяжении трех месяцев каждую ночь автоматически собирается и выкладывается новая сборка.
Как это происходит?
Самописная система обращается к сборщику обновлений и автоматически ставит все возможные обновления. Смотрит, что упало на этапе установки.
Затем машина собирает все имеющиеся дистрибутивы — у нас их 8 редакций — и ночью развёртывает локальные установки.
Ночные билды мы не выкладываем в открытый доступ. Система опять фиксирует, всё ли установилось. Если всё в порядке, запускаются все автотесты.
Утром тестировщик проверяет логи и смотрит, где и что упало, где разработчик допустил ошибку, где нужно поправить автотест.
Модульные-тесты
Большая часть наших тестов — UI, а не Unit. Модульные тесты мы используем только для важных компонентов: главный модуль, CRM, интернет-магазин.
В некоторых компаниях есть разногласия по поводу того, кто должен писать модульные тесты.
На мой взгляд, их могут писать и тестировщики, и разработчики. У нас сложилось так, что их пишут разработчики.
Для прогона модульных тестов используем стандартный инструмент PHP unit. Просто вызываем метод. Смотрим, как он работает с параметрами, которые даются на вход. И смотрим ответ.
URL checker
Это моя давняя идея. Возможно, кому-то она будет полезна.
Всё, что можно найти и вытащить из кода страницы, робот складывает в лог со скриншотами.
Написать такого робота крайне просто, но он может сэкономить много времени.
Component checker
Наш component checker работает так:
Если вы наш партнер, и когда-либо отдавали модуль нашему модератору в «Маркетплейс» на модерацию, знайте, что мы обязательно прогоняем все ваши решения с помощью этого чекера.
Визуальный эксперимент
Сейчас мы проводим небольшой эксперимент — переводим планы тестирования из текста в визуальные схемы. Они похожи на диаграммы связей.
На них сразу видно, какие элементы продукта с чем связаны: на что влияет сохранение заказов, или что влияет на само сохранение? Что и как может повлиять на схему складского учета?
Так тестировщик может быстро оценить — на какие элементы повлияют изменения в том или ином компоненте.
Качество тестирования
Мы отказались от избыточного тестирования. Я сторонник принципа достаточности.
Сейчас мы очень мало тестируем на «защиту от дурака». Например, в поле ввода денежной суммы, скорее всего, не будем вводить буквы.
В некоторых компаниях это практикуется. Некоторые считают, что любой хороший тестировщик не обязан ограничивать себя прописанными прецедентами тестирования. Он может их просто выдумать.
Но для нас этот подход перестал работать — в наших реалиях хватает «достаточного» тестирования.
Достаточность определяется потребностями рынка и сроками выпуска продукта. Мы можем тестировать новую фичу год, но опоздать с выпуском.
Поэтому мы придерживаемся принципа достаточности. Не выпускаем сырой продукт, потому что нас выкинут с рынка. И не тянем с выпуском вылизанной фичи, которая будет устаревшей на момент релиза.
* * *
Мне интересно ваше мнение о прочитанном. Как проводится тестирование в вашей компании?
Что означает «Ночные сборки»?
Некоторое время я использовал проекты с открытым исходным кодом и разрабатывал приложения с открытым исходным кодом, и время от времени я сталкивался со словами «Ночная сборка», и мне всегда было любопытно, что это на самом деле означает. Означает ли это буквально, что проекты выполняются исключительно как побочные проекты (обычно ночью, после того, как все закончили свои дневные работы), и нет реального участника/специальной группы разработчиков, или это более сложно?
Нет, это означает, что каждую ночь создается все, что было проверено в системе контроля версий. Эта сборка является «ночной сборкой».
Это означает, что сборка выполняется в конце каждого дня разработки. Если вы используете сервер непрерывной интеграции, он, как правило, будет настроен для построения кода и запуска модульных тестов при каждой регистрации. В конце каждого дня вы можете запускать более масштабные тесты, например, регрессионные и интеграционные тесты: которые занимают слишком много времени при каждой регистрации, и они будут срабатывать после ночной сборки. Если у вас есть полный непрерывная доставка конвейер, ночная сборка может также использоваться для развертывания встроенного кода в средах для пользовательского тестирования.
Этот термин часто используется для крупных проектов, где полная переработка готового продукта из исходного кода занимает слишком много времени для отдельного разработчика, чтобы сделать это как часть их обычного цикла разработки.
Вместо этого полная перестройка выполняется автоматически в течение ночи, так что сборочный компьютер имеет 8-10-12 часов для сборки и готовит ее для разработчиков, приходящих на следующее утро, чтобы они могли продолжить работу над своим крошечным кусочком сверху. новой версии.
В наши дни проект часто включает в себя множество тестов, обеспечивающих правильную работу кода, а также генерирует и публикует документацию из исходного кода (например, javadoc).
Что такое «ночные» сборки?
Когда вы ссылаетесь на выпуски Ubuntu, я сталкивался с тем, что называется «ночными» сборками. Что означают «ночные» сборки?
3 ответа
Поскольку программное обеспечение разрабатывается, прежде чем оно будет «выпущено», программное обеспечение в его невыпущенном или «незавершенном» состоянии все еще может быть вполне пригодным для использования в любой момент времени, поскольку разработчики вносят в него изменения, а также добавляя функции или готовя его к будущему выпуску.
Ежедневная сборка обычно означает, что какая-то машина захватывает неизданное программное обеспечение каждую ночь в определенный момент времени, компилирует его и ставит его для тестирования разработчиками. [!d1 ]
Очевидно, что это может быть или не быть полезным, в зависимости от того, на какой стадии развития он находится, какова стратегия выпуска для этого проекта и т. д. То, что вы тестируете, является мгновенным снимком незавершенного программного обеспечения в один момент времени.
Иногда программное обеспечение может быть почти готово к выпуску, и в этом случае он часто будет работать уже неплохо. Если разработчики объявили о «замораживании», это означает, что они минимизируют изменения, только фиксируя существующие ошибки. На этом этапе ночная сборка программного обеспечения с большей вероятностью будет вполне пригодна, поскольку она приближается к времени выпуска.
Если вы говорите о ежедневных сборках почти [!d4 ] или компакт-диск с установщиком, то это сборки из среды установки, основанные на моментальных снимках текущего процесса разработки. Все вышеизложенное применимо. Это, должно быть, очень хорошо работает из-за их стратегии выпуска, хотя для некоторых вещей нет ничего необычного.
Нет смысла устанавливать какую-либо часть программного обеспечения из ежедневной сборки, если вы не тестируете функции, которые в настоящее время в разработке и еще не выпущен, и вы готовы мириться с тем, что он немного сломан или незакончен.
Поскольку программное обеспечение разрабатывается, прежде чем оно будет «выпущено», программное обеспечение в его невыпущенном или «незавершенном» состоянии все еще может быть вполне пригодным для использования в любой момент времени, поскольку разработчики вносят в него изменения, а также добавляя функции или готовя его к будущему выпуску.
Суточная сборка обычно означает, что какая-то машина захватывает неизданное программное обеспечение каждую ночь в определенный момент времени, компилирует его и ставит его для тестирования разработчиками.
Очевидно, что это может быть или не быть пригодным к использованию, в зависимости от того, на какой стадии развития он находится, что такое стратегия выпуска для этого проекта и т. д. То, что вы тестируете, является мгновенным снимком незавершенного программного обеспечения в один момент времени.
Иногда программное обеспечение может быть очень почти готово к выпуску, и в этом случае он часто будет работать уже неплохо. Если разработчики объявили о «замораживании», это означает, что они минимизируют изменения, только фиксируя существующие ошибки. На этом этапе ночная сборка программного обеспечения, скорее всего, будет вполне пригодной для использования, поскольку она приближается к времени выпуска.
Нет смысла устанавливать какую-либо часть программного обеспечения из ежедневной сборки, если вы не тестируете функции, которые в настоящее время в разработке и еще не выпущен, и вы готовы мириться с тем, что он немного сломан или незакончен.