LINUX.ORG.RU
Форум — Development  

Continious Delivery Software

 ,


1

3

Привет, пацанчики. Пушу в ветку Development первый раз. Раньше все темы бомбил в ветку Admin, т.к. приходилось решать задачи, связанные с админкой. ПО я не пишу, поэтому в этом я полный ноль.

Работодатель захотел приватный gitlab сервер и go.cd. Я так понял, есть еще аналоги со схожим функционалом типа jenkins и teamcity. Все это я установил, запустил. Но вот засада встала c go continous delivery.

Я совсем ничего не знаю о циклах разработки ПО. О тестах (какие бывают, что делают), которые там должны гоняться. Об этапах разработки и тестирования и о инструментах. О том, как тесты пишутся и на чем.

Там вроде еще и автодеплой есть, когда код берется с gitlab, прогоняются тесты и все это выкладывается на боевой сервер.

Я не понимаю, как это continious delivery настраивать.

Вобщем мне бы советы, где толковые статьи есть почитать на эту тему.

Добавил чуть позже: Смотрите, в частности меня интересуют для приложений Django

Функционал «build» deployment

  • По build - вообще нужно какое-то время тратить на сборку/компилирование приложения или это вообще не нужно?
  • Как к этой херне тесты прикручивать?
  • Это вообще нормально Django проекты деплоить на такой штуке?
★

Последнее исправление: dopedopedope (всего исправлений: 4)
← Протокол доступа к ресурсам. REST-а мало.
Разница между обращением к методу класса -> и . →

Я так понял, ты про Continuous Integration? Да про него на хабре часто пишут (ща меня какашками закидают за хабр).

DeadEye ★★★★★
()
Последнее исправление: DeadEye (всего исправлений: 1)

Ты все в кучу валишь. Какие тесты бывают и как и когда запускаются и как их дизайнить — это задача тестировщиков.

Задача CI/CD — автоматизировать заданный процесс сборки и тестирования.

Крутые слайды есть, например, у BuildBot:

http://releng.polymtl.ca/RELENG2013/html/slides/buildbot-talk/index.html

Вообще доки по Buildbot - одно из лучших описаний CI-систем вообще. Там на примере конкретной реализации считай показаны все детали любой сборочной системы, причем буквально в разрезе. Потом уже неважно, хоть Jenkins, хоть Bamboo, хоть TeamCity настраивать - принципы те же.

alpha ★★★★★
()
Ответ на: комментарий от alpha

А если конкретно мы занимаемся разработкой приложений на django, там есть этап под названием «процесс сборки»?

Там вроде ничего собирать не надо. Написал проект, выложил на сервер с настроенным uwsgi

dopedopedope ★
() автор топика
Ответ на: комментарий от dopedopedope

Сборка имеется в виду в самом широком смысле - это не столько компилирование кода, сколько именно сбор исходных данных из разных источников и получение из них финального результата — «артефакта», для прогона тестов или для окончательного релиза.

Вообще CI/CD — это не какая-то особенная странная процедура или сборник рецептов. Это просто идеология максимальной автоматизации процесса сборки и тестирования так чтобы оперативно получать результаты, желательно на каждый коммит. При этом в самом этом CI/CD не содержится никаких сведений о том, что конкретно надо делать. Это зависит от приложения и от поставленной задачи.

А все CI-системы - это просто планировщики. Они позволяют выполнить некоторый набор шагов, передавая параметры из одного шага в другой. Что там происходит внутри «шага» - это не их дело, а того баш-скрипта, который ты туда запихнешь. Будет он выполнять make или rsync — дело десятое.

К примеру для того же django-приложения результатом может быть и просто тарбол с исходниками. У нас как-то «сборка релиза» означала что надо было: выгрузить код собственно приложения, собрать пдфку с документацией по нему, собрать дополнительно bundle со всеми python-зависимостями, правильно переименовать файлы в соответствии с версией, заархивировать всё, что получилось, и залить на shared-хранилище.

А в твоем случае вероятно результатом будет сам сервис. Для абстрактного веб-приложения в вакууме можно такие шаги написать:


"Сборка":
- выкачать последний исходный код приложения из репозитория,
- добавить конфиг тестовой БД,
- залить на тестовый сервер

Тестирование:
- Запустить набор тестов, получить результаты
- Если все ок, отметить этот коммит как успешный

Деплой = та же "сборка" только с другим параметрами:
- выкачать успешный коммит из репозитория,
- добавить конфиг production-БД,
- залить на production-сервер

При этом видно что разные стадии надо выполнять на разных серверах, с разными правами доступа и можно перезапускать независимо друг от друга. Поэтому разбиение на куски имеет смысл.

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

А если например у тебя появятся 100500 видов установок: на центось/убунту, Postgres или MySQL, в virtualenv, системные пакеты или docker, python2.7 или python3.4, и т.д. и т.п, тогда можно «размножить» задачи по установке, а тестовую задачу оставить одну, но запускать её с разными параметрами.

И вот тут мы и приходим к CI-системам, которые позволяют достаточно сконфигурировать такие зависимости, настроить сборку по событиям или по таймеру, получать уведомления, смотреть на графики, пугать начальство красными лампочками и сиренами при падении тестов, и всё такое прочее.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Спасибо за то, что разьяснили вкратце суть этого механизма.

DeadEye ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Протокол доступа к ресурсам. REST-а мало.
Development
Разница между обращением к методу класса -> и . →