По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В статье будет рассмотрена пошаговая настройка факса для FreePBX 13-й версии + Asterisk 13 версии. В веб-интерфейсе произошло много изменений, однако, это так же коснулось и алгоритмов настройки. Пункт в настройках остался на том же месте – Settings → Fax Configuration По какой-то неведомой причине при попадании в это меню, он уже называется «Fax Options» Пройдемся по пунктам меню: Default Fax header – идентификатор, который будет указан на каждом листе отправленного факса, к примеру ФИО сотрудника, отправившего факс. : Default Local Station Identifier – как правило, номер факса: Outgoing Email address – адрес, который будет в поле «От» : Email address – почтовый адрес, на который приходит факт если использовать фича-код «Набрать Системный Факс», или если не указан никакой другой адрес. : Error Correction Mode – Режим исправления ошибок (ecm) : MaximumMinimum transfer rate – соответственно скорость передачи (дефолтное значение - 14400) : Default Paper Size – размер документа, который будет использоваться, если документ не попадает ни под какой стандарт Следующим шагом будет создание экстеншена (Applications → Extensions → Quick Create Extension): В поле «Type» можно выбрать значение как «Virtual», так и любой другой – большого значения это не имеет. Примечание: Во втором шаге быстрого создания экстеншена можно сразу указать e-mail адрес, на который будут приходить факсы. Далее необходимо открыть панель управления пользователями: Admin → User Management и нажать на иконку «Открыть» (первая с левого края). Далее необходимо проверить указан ли e-mail адрес у данного пользователя, и, если да – нужно перейти в поле «Fax», и в поле «Enabled» указать «Yes», так же, как и в поле «Store Locally». В общем и целом, на этом настройка факса для приёма завешена. Теперь можно отправить любой вызов на факс, т.к в “Inbound Routes” появилась опция «Fax Recipient» Ниже приведу приведу скриншот из меню настройки IVR (Applications → IVR → Add New). Необходимо выбрать в поле Destination – Fax Recipient – test (1000) . Это именно тот пользователь, что был нами создан. Теперь, при наборе номера и нажатии «9» в голосовом меню вы услышите столь знакомый тоновый сигнал факса.
img
На этот раз мы спешим поделиться процессом настройки подключения (SIP – транка) на FreePBX 13 на примере оператора Beeline. Настройка транка Настройка транка от данного оператора не отличается какими-то особенным параметрами – все происходит так же, как и в случае других операторов. После покупки аккаунта, вам должны предоставить следующие данные: Опция В нашем примере Телефонный номер +74956661313 Логин(UserID) 74956661313 Пароль test Сервер sip.beeline.ru Домен sip.beeline.ru OutboundProxy msk.beeline.ru (DNS SRV-запись) Создаем новый транк. Для этого необходимо перейти по следующему пути: Connectivity → Trunks. Далее необходимо кликнуть на кнопку создания нового транка (+ Add Trunk). Выбираем опцию создания SIP (chan_sip) Trunk. Нужно присвоить транку имя и указать Outbound CallerID (номер, который вы получили от провайдера). Далее переходим во вкладку sip Settings и вносим необходимые настройки в поле PEER Details вкладки Outgoing: Ниже приведены настройки для поля PEER Details в текстовом виде, для удобства: username=74956661313 //ваш логин (он же номер) type=friend secret=test //ваш пароль outboundproxy=msk.sip.beeline.ru insecure=port,invite host=sip.beeline.ru fromuser=74956661313 fromdomain=sip.beeline.ru dtmfmode=rfc2833 disallow=all directmedia=no defaultuser=74956661313 context=from-trunk allow=alaw&ulaw Далее переходим во вкладку Incoming и настраиваем строку регистрации: Для оператора Билайн строка регистрации имеет следующий вид: Логин:пароль@sip.beeline.ru/ваш_номер Логин – это ваш так называемый AuthUserID Нажимаем Submit и Apply Config. Маршрутизация вызовов Для настройки входящего маршрута переходим в Connectivity → Inbound Routes, далее кликаем на кнопку создания нового маршрута (+ Add Inbound Route). Присваиваем имя и указываем DID Number – удобнее всего оба поля заполнить значением вашего номера, и указываем куда будет маршрутизироваться входящий вызов: Кликаем Submit и Apply Config, переходим к настройке исходящего маршрута: во вкладке Connectivity – Outbound Routes, кликаем + Add Outbound Route. Указываем имя маршрута, указываем CID и выбираем транк Далее переходим во вкладку Dial Patterns и в поле Match Pattern ставим одну-единственную точку (для маршрутизации всех вызовов в сторону Билайна). После этого кликаем Submit и Apply Config – на этом настройка транка в FreePBX 13 для оператора Билайн закончена.
img
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через 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.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59