Посты с тэгом ci


[recovery mode] Мысли о развёртывании веб-приложений на тестовом сервере


Предисловие


Нижеследующий текст − результат практического опыта и самообразовательных порывов человека, не имеющего систематического образования ни в одной из областей, о которых он (то есть я) берётся рассуждать. Поэтому заумные рассуждения здесь будут перемежаться банальностями. Бейте меня за первые и игнорируйте вторые. Для кого-то и они могут стать откровением.

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

Основной упор я буду делать на применение разных верс


Локальный Continuous Integration сервер

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

Принцип работы у всех примерно один:
  • скачать код
  • создать окружение
  • установить (собрать) код
  • запустить и протестировать
  • отправить уведомление
Это можно сделать самостоятельно, например при помощи fabric, cron, chroot или docker или при помощи готовых CI серверов:


Локальный Continuous Integration сервер

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

Принцип работы у всех примерно один:
  • скачать код
  • создать окружение
  • установить (собрать) код
  • запустить и протестировать
  • отправить уведомление
Это можно сделать самостоятельно, например при помощи fabric, cron, chroot или docker или при помощи готовых CI серверов:


Jenkins – Continuous Integration для Django проектов

Интро Писать или не писать тесты? Для меня и моих коллег даже вопрос так не стоит. Конечно писАть! Однако, с появлением тестов и увеличением команды разработки, появляется одна проблема – “забыл запустить тесты“. Проекты в основном на python & Django и для автоматизации можно написать bash-скрипт и запускать его по cron. Можно воспользоваться сервисами, например: https://travis-ci.com/. [...]



HowTo: continuous integration Django в Jenkins с помощью Selenium

Хабы: Django

Это шпаргалка раскрывающая раздел «Интеграция Selenium тестов» статьи Настройка Jenkins для django проекта с нуля. А именно как запускать Selenium тесты на удалённом сервере Jenkins у которого нет монитора и форточек.
Читать дальше →



Django Framework / Настройка Jenkins для django проекта с нуля

Всем привет.

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

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

В качестве новой системы был выбран Jenkins, о его установке и настройке для django-проекта и пойдет речь в этой статье. Кто заинтересовался, добро пожаловать под кат.