По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через SSH, клонировать клонировать репозиторий с новым кодом, собрать его и запустить через командную строку. Да, такой способ работает, но он малоэффективен. Сегодня мы поговорим об автоматизации процесса разработки и выхода новых версий.
CI и CD – это два сокращения, которые означают Continuous Integration (Непрерывная интеграция) и Continuous Delivery (Непрерывное развертывание).
CI
CI описывает процесс добавления изменений в репозиторий. Ниже схематически представлен простой пример коллективной разработки.
Одновременно может работать целая группа людей, но все изменения передаются в главную ветку master поэтапно. Хотя даже в такой простой схеме возникает несколько вопросов.
Как мы узнаем, что код, который идет в ветку master, компилируется?
Мы хотим, чтобы разработчики писали тесты для кода. Как быть уверенными в том, что тестовое покрытие не уменьшится?
Все сотрудники команды должны форматировать код в соответствие с определенным стилем. Как отследить возможные нарушения?
Конечно же, все это можно проверить вручную. Но такой подход весьма хаотичен. Кроме того, по мере разрастания команды выполнять подобные проверки становится сложнее.
CI используется для автоматизации выше обозначенных пунктов.
Начнем с первого пункта. Как можно проверить, что новые изменения не сломают сборку? Для этого нам потребуется еще один блок в схеме.
Большинство CI-процессов можно описать по следующему алгоритму.
При открытии каждого Pull Request (запроса на включение изменений) и отправке новых изменений, Git-сервер отправляет уведомление CI-серверу.
CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting) и сливает ее с основной веткой master.
Затем запускается скрипт сборки. Например ./gradlew build.
Если команда возвращает код «0», то сборка прошла успешно. Все остальные значения считаются ошибкой.
CI-сервер отправляет запрос на Git-сервер с результатом сборки.
Если сборка прошла без ошибок, то Pull Request разрешается слить. В противном случае он блокируется.
Данный процесс гарантирует, что код, попадающий в ветку master, не сломает дальнейшие сборки.
Проверка тестового покрытия
Давайте немного усложним задачу. Предположим, нам захотелось установить минимальный охват тестового покрытия. Это означает, что в любой момент времени покрытие ветки master должно быть не менее 50%. Плагин Jacoco идеально справляется с этой задачей. Вы просто настраиваете его так, чтобы при охвате тестового покрытия ниже допустимого, сборка уходила в ошибку.
Реализовать такой подход проще некуда. Но есть небольшая оговорка. Этот метод работает только при условии, что плагин настраивался на старте проекта.
Представим ситуацию: вы работаете над проектом, которому уже 5 лет. С момента первого коммита никто не проверял тестовое покрытие. Разработчики добавляли тесты в случайном порядке и без какой-либо организации. Но вот однажды вы решаете увеличить количество тестов. Вы настраиваете плагин Jacoco на минимальную планку в 60%. Спустя какое-то время разработчик открывает новый Pull Request. Затем разработчики вдруг понимают, что покрытие – всего лишь 30%. Так что для успешного закрытия задачи нужно покрыть не менее 30% кода продукта. Как вы можете догадаться, для проекта 5-летней давности – это практически неразрешимая проблема.
Но что, если будут проверяться только будущие изменения в коде, а не весь продукт? Если в Pull Request разработчик изменит 200 строк, то нужно будет охватить не менее 120 из них (при тестовом покрытии в 60%). Тогда не придется проходить по множеству модулей, которые не относятся к задаче. В принципе, проблема решаема. Но как применить все это к проекту? К счастью, есть решение.
Отчет Jacoco отправляется на сервер тестового покрытия.
Одно из самых популярных решений – SonarCloud.
Сервер хранит статистику по предыдущим вычислениям. Это очень удобно: вычислять тестовое покрытие не только всего кода, но и будущих изменений. Затем результат анализа отправляется на CI-сервер, который перенаправляет его на Git-сервер.
Такая рабочая модель позволяет применять культуру обязательного тестирования на любой стадии развития продукта, поскольку проверяется лишь часть изменений.
Если говорить о стиле оформления кода, то отличий практически нет. Можете попробовать плагин Checkstyle. Он автоматически отклоняет сборку, которая нарушает любое из заявленных требований. Например, в коде есть неиспользованный импорт. Кроме того, вы можете присмотреться к облачным сервисам, которые выполняют анализ кода и визуально отображают результаты в виде графиков (SonarCloud это тоже умеет).
CD
CD описывает процесс автоматического развертывания новой версии продукта.
Давайте еще немного подкорректируем схему CI. Вот так конвейерный процесс CI/CD мог бы выглядеть в реальном проекте.
Первое отличие – теперь CI-сервер называется CI/CD-сервером. Дело в том, что зачастую оба процесса (CI и CD) выполняются одним и тем же диспетчером задач. Так что мы будем рассматривать именно этот случай.
Но так бывает не всегда. Например, задачи по интеграции могут делегироваться на GitLab CI, а задачи по доставке – отдаваться в Jenkins.
Правая часть схемы изображает CI. Мы обсудили ее выше. Слева показана CD. Задача по CD создает проект (или повторно использует артефакты, полученные на стадии CI) и развертывает его на конечном сервере.
Стоит отметить, что сервер в нашем случае – это понятие абстрактное. Например, развертывание может выполняться в кластер Kubernetes. Так что самих серверов может быть несколько.
Обычно после стадии развертывания на почту приходят сообщения о выполнении. Например, CD-сервер может уведомлять подписчиков об успешном развертывании/ошибках.
В любом случае, возникает важный вопрос. В какой момент мы должны запускать задачи по CD? Триггеры могут быть разными.
Развертывание после каждого слияния Pull Request.
Развертывание по расписанию.
Развертывание после каждого слияния Pull Request с определенной веткой.
Сочетание нескольких вариантов.
В первом пункте процесс выстроен так, что задачи по CI и CD всегда выполняются последовательно. Данный подход весьма популярен при разработке программ с исходным кодом. Библиотека Semantic Release помогает настроить проект для прозрачной интеграции данной модели.
Важно помнить о трактовке понятия deploy (развертывание). Это не всегда «что-то где-то запустить». Например, при разработке библиотеки, нет никакого запуска. В данном случае процесс развертывания означает выпуск новой версии библиотеки.
Второй пункт не зависит от процесса CI, ведь проект развертывается по определенному расписанию. Например, ежедневно в 01:00.
Третий пункт аналогичен первому, но с небольшими отличиями. Предположим, в репозитории у нас есть 2 основные ветки: develop и master. В develop содержатся самые последние изменения, а в master – только релизы версий. Если мы хотим развертывать только ветку master, то не нужно вызывать CD-задачу по слиянию в develop.
Последний пункт – это сочетание подходов. Например, ветку develop можно развертывать по расписанию в среду разработки. А ветку master – в реальную среду по каждому слиянию Pull Request.
Инструменты
На рынке доступно множество решений по автоматизации процессов CI/CD. Ниже представлено несколько продуктов.
Jenkins. Один из самых востребованных инструментов CI/CD в мире. Свою популярность он заслужил, благодаря политике открытого кода (open-source). То есть вам не нужно ни за что платить. В Jenkins вы можете императивно описывать конвейеры сборки с помощью Groovy. С одной стороны это достаточно гибкое решение, но с другой – требует более высокого уровня квалификации.
GitHub Actions. Этот инструмент для CI/CD доступен для GitHub и GitHub Enterprise. В отличие от Jenkins, GitHub Actions предлагает декларативные сценарии сборки с YAML-конфигурацией. Кроме того, в данном решении доступна интеграция с различными системами обеспечения качества (например SonarCube). Таким образом, сборку можно описать в нескольких текстовых строках.
GitLab CI. Во многом похож на GitHub Actions, но со своими особенностями. Например, GitLab CI может указывать на определенные тесты, вызывающие ошибку в сборке.
Travis CI. Облачный CI/CD-сервис. Предлагает множество возможностей, не требующих сложных настроек. Например, шифрование данных, которые следует скрыть в публичном репозитории. Есть и приятный бонус в том, что Travis CI можно совершенно бесплатно использовать в публичных open-source проектах на GitHub, GitLab и BitBucket.
В данной статье пойдет речь о голосовых уведомлениях (Announcements)
Модуль уведомлений используется для проигрывания голосовых записей абонентам и после проигрыша маршрутизации звонка на нужное направление. Важно не путать модуль Announcements (Голосовые уведомления) и System Recordings (Системные записи) . Модуль системных записей – это приложение в котором происходит загрузка или запись самих голосовых сообщений. Модуль Announcements просто позволяет проиграть одну из этих записей.
Важно: для использования этого модуля предварительно записи нужно загрузить или создать с помощью модуля System Recordings.
Модуль Announcements в FreePBX 13 находится по следующему пути:
Applications – Announcements
Для создания уведомления нужно нажать на кнопку «Add», что приведет к открытию интерфейса создания сообщений
Далее опишем каждое поле в данном интерфейсе:
Description – названиеописание самого уведомления, проще всегда писать какое-то название, которое описывает назначение голосового сообщения.
Recording – необходимо выбрать запись, созданную с помощью интерфейса System Recordings
Repeat – количество повторений данного голосового уведомления при нажатии на кнопку, важный момент: если необходима пауза между повторениями, требуется добавить паузу в саму запись
Allow Skip – возможность пропускать уведомление с помощью нажатия на кнопку (полезно, если абонент очень часто звонит на данный номер)
Return to IVR – возврат звонка на IVR, игнорируя выбранное направление звонка с помощью опции ниже. Звонок вернется на последний IVR в цепочке звонков.
Don’t answer Channel – по дефолту значение стоит «No», т.е ответ на звонок и проигрывание сообщения. Если стоит «Yes», то голосовое уведомление будет отправлено абоненту как «Early Media», но многие провайдеры не поддерживают данную опцию.
Destination after Playback – направление звонка после проигрыша сообщения. В данном конкретном примере указана ринг-группа, однако вариантов направлений масса
На этом все, придумывайте собственные сценарии использования уведомлений, ведь спектр крайне широк!
Настроим VoIP-шлюз Eltex TAU-16.IP в качестве мини - АТС.Данное устройство нет смысла использовать как полноценную мини - АТС, так как в ней будут отсутствовать многие функции, но в некоторых случаях такой вариант тоже применим.
$dbName_ecom = "to-www_ecom";
$GoodID = "3152129363";
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName_ecom) or die(mysql_error());
$query_ecom = "SELECT `model`, `itemimage1`, `price`, `discount`, `url`, `preview115`, `vendor`, `vendorCode` FROM `items` WHERE itemid = '$GoodID';";
$res_ecom=mysql_query($query_ecom) or die(mysql_error());
$row_ecom = mysql_fetch_array($res_ecom);
echo 'Кстати, купить '.$row_ecom['vendor'].' '.$row_ecom['vendorCode'].' можно в нашем магазине Merion Shop по ссылке ниже. С настройкой поможем 🔧
Купить '.$row_ecom['model'].''.number_format(intval($row_ecom['price']) * (1 - (intval($row_ecom['discount'])) / 100), 0, ',', ' ').' ₽';
$dbName_ecom = "to-www_02";
$GoodID = "3152129363";
mysql_connect($hostname,$username,$password) OR DIE("Не могу создать соединение ");
mysql_select_db($dbName_ecom) or die(mysql_error());
Главным достоинством шлюза является поддержка SIP-транков и наличие аналоговых портов FXS одновременно. Обычно Вы можете приобрести более доступную аналоговую мини - АТС с таким же количеством аналоговых портов, но возможность подключения входящих SIP-линий отсутствует или предполагает дополнительные затраты на лицензии или дополнительное оборудования. Или же Вы можете приобрести VoIP АТС с поддержкой SIP-транков и телефонов из коробки, и так же значительно дешевле. Но чтобы подключить к ней аналоговые телефоны необходимо докупить VoIP шлюз(ы) с количеством портов, соответствующим количеству аппаратов.
В первую очередь следует настроить сеть. В самом простом случае, достаточно изменить адрес шлюза, который установлен по-умолчанию. Настройки выполняются в разделе "Сетевые настройки/Сеть":
Если же необходимо разделить сеть для голоса и для управления, следует настроить сети на вкладке "VLAN", указав адреса для каждой сети, а так же указать, по каким сетям будет передаваться голос, сигнальная информация и осуществляться управление (указывается внизу страницы).
Настройки выполняются в разделе "Сетевые настройки/VLAN":
Общий принцип настройки устройства в качестве АТС заключается в следующем: создается два SIP-профиля, один из которых отвечает за связь с внешним миром (с оператором VoIP), а второй за работу аналоговых портов. В первом профиле задаются настройки транка для связи с оператором адрес сервера, порт, данные для регистрации (если требуется), поддерживаемые кодеки и план нумерации, согласно которому устройство будет отправлять вызовы на этот транк. Второй профиль создается без регистрации и дает возможность совершать вызовы по коротким номерам внутри шлюза. План набора этого профиля указывает устройству, какие вызовы выполняются внутри шлюза, а какие следует направлять во внешний мир.
Итак, настройки профиля для связи с провайдером. Выполняются в разделе "PBX / Профили SIP/H323 / Профиль 1". Во вкладке "SIP настройки профиля":
Здесь указываются данные, которые предоставляет оператор связи. Основные данные адрес, куда должен обращаться шлюз для совершения вызовов. Если используется транк с регистрацией, необходимо включить эту функцию в поле 1, и указать данные для регистрации (логин/пароль) в полях 2 и 3. Остальные настройки можно оставить по-умолчанию.
Во вкладке "Кодеки" задаются используемые кодеки, а так же есть возможность задать настройки для передачи модема и факса. Эти данные так же обычно предоставляет оператор. В общем случае, у нас всегда должен работать кодек G.711a. Для успешного прохождения факсов обычно отключаем опцию "Передача модема", а в параметре "Основной кодек передачи факса" выбираем "Т38", резервный G.711a. Так же, с нашим оператором возникают проблемы с опциями "Эхокомпенсатор" и "Комфортный шум", поэтому их так же деактивируем.
Переходим ко вкладке "План набора". Настройки на этой вкладке позволяют совершать вызовы через сеть нашего оператора. Здесь указываем префиксы, набрав которые, абонент должен звонить через внешнюю сеть. В данном случае, удобнее использовать опцию "Табличный план набора":
Нажимаем кнопку "Добавить префикс":
Указываем префикс, минимальное количество цифр в набираемом номере. В поле "Протокол и направление" в нашем случае указываем "SIP-транк" (транк по ip-адресу без регистрации). Тип номера Subscriber (при звонках внутри оператора связи) или National (при звонках на сеть МГ). На самом деле, вероятнее всего, на стороне оператора этот параметр все равно будет корректироваться. В поле "ip-адрес" указывается адрес станции оператора, на который обращается шлюз для выполнения вызовов. Этот же адрес указывался в настройках SIP-профиля. В форме "Абонентские порты" можно указать, какие именно абоненты могут выполнять вызовы по этому правилу.
Переходим к настройке Профиля 2 (для локальных абонентов).
Собственно, вся настройка сводится к настройке Плана набора, в основных настройках все поля оставляем по-умолчанию.
Во вкладке "План набора" выбираем опцию "Строчный план набора" и вписываем следующую строчку:
1xx@192.168.130.58|x.@192.168.130.57
где:
1xx - нумерация, используемая для внутренних абонентов. В нашем случае, внутренние номера телефонов имеют вид 101,102, 103 и т.д.
192.168.130.58 локальный адрес нашего устройства. То есть, если внутренний абонент набирает номер вида 101, 102 и т.д., вызов осуществляется внутри устройства.
x.@192.168.130.57 - данная строчка означает, что все остальные вызовы будут направляться на адрес 192.168.130.57 (адрес оператора), то есть через транк.
Теперь настроим абонентские порты. Переходим на вкладку "PBX/Абонентские порты"
В этой вкладке задаем внутренние номера, а в поле "SIP/H323 профиль" указываем тот профиль, который настраивали для внутренней связи ( в нашем случае, Профиль 2).
После выполнения этих настроек исходящая связь уже должна работать. Остается настроить входящую связь.
Следует помнить, что при настройке параметров на каждой вкладке следует нажимать кнопку "Применить изменения". После выполнения всех настроек необходимо нажать кнопку "Сохранить". В противном случае, после перезагрузки устройства настройки будут утеряны. Эту особенность так же можно использовать в случае, когда что-то пошло не так и необходимо вернуть исходные настройки.
Перейдем к настройке входящих вызовов. Открываем вкладку "PBX/Группы вызова". Здесь нажимаем кнопку "Новая группа":
Имя группы любое, пароль пропускаем, телефонный номер внешний номер, на который совершается вызов и который будет обозначен как B-номер во входящем вызове. Тип группы: групповой звонят все телефоны в группе, серийный после таймаута начинает звонить следующий телефон, при этом предыдущий продолжает звонить, циклический вызов по очереди переходит на следующий в списке порт. "SIP-профиль" - профиль, на котором работают внутренние номера (в нашем случае, Профиль 2). Кнопку "В работе" необходимо включить.
После добавления группы вызова, ее нужно отредактировать:
Для редактирования необходимо нажать иконку в столбце "Изменить".
Здесь появилась новая вкладка "Порты", где можно добавлять или удалять порты, на которые будет поступать вызов и задавать очередность поступления вызова.
На этом настройка шлюза Eltex TAU-16.IP закончена. Настройки применимы на всех устройствах серии ELTEX TAU стоечного исполнения (16,32,36,72 порта). Версия ПО в данном случае - 2.18.0.35