По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через 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.
По данным компании Mediascope среднесуточный охват Telegram
достиг 47%
(за декабрь 2023 года среди аудитории старше 12 лет). Это значит, что ??почти половина населения России хотя бы раз в день пользуется мессенджером. По своему опыту скажем, что Телеграм нужен не только для общения с друзьями и близкими, он также служит отличным инструментом для бизнеса. В этом материале мы рассмотрим, как без навыков программирования создать Телеграм-бота, который будет полезен для разных задач.
Что такое бот в Телеграм?
Telegram-бот — это специальная программа, которая может выполнять заданные действия в мессенджере. Обычно под этим понимается набор функций от модерации чата, предоставления новостей или скрипта продаж до игр и организации задач. Стоит отметить, что функционал Telegram-ботов постоянно расширяется, а толковый бот может освободить пользователя от рутинных дел, которые отнимают время. Здесь все зависит от навыков разработчика. Хочется дать дисклеймер, что сложные Телеграм-боты могут выглядеть как полноценное веб-приложение, для создания которого необходимо уметь кодить. Мы же пройдемся по программам, где можно сделать почти то же самое, но без навыков программирования.
Четыре причины создать собственный Телеграм-бот:
Автоматизация задач. Например, направлять уведомления, планировать встречи, собирать информацию из внешних источников: котировки ценных бумаг, новости, погода, расписание и многое другое. В отличие от нанятого сотрудника бот может быть доступен в любое время и в любой день.
Клиентский сервис и поддержка: запись на услугу, обработка запроса, предоставление информации, сбор обратную связь или проведение опроса — все это можно доверить боту. Здесь он берет на себя функции и продавца-консультанта, и email-рассылки.
Общение, развлечение и игры: Телеграм-бот поможет выбрать фильм, найти заведения поблизости, сыграет с вами в виселицу или даст случайно выбранный совет.
Бот-инструмент: может быть полезен, когда надо скачать файлы из соцсетей, запустить отложенную рассылку, расшифровать голосовое сообщение в текст и многое другое.
Полезные конструкторы для создания бота
Бота можно легко создать с помощью конструктора. В его основе лежит простой принцип: бот собирается из кирпичиков необходимых функций. Такие программы могут быть бесплатными или работать по подписке, а освоить их можно за несколько часов.
Manybot
Где найти:
https://manybot.io/
Стоимость
(ежемесячно): бесплатно.
Это тоже бот, заточенный под Telegram. Сервис позволяет пользователям создавать своих собственных ботов без необходимости знаний программирования. Для создания бота достаточно пройти несложный процесс настройки, выбрав нужные опции и функции. Когда бот будет готов к работе, он сможет выполнять простые задачи: отправлять уведомления, отвечать на вопросы пользователей или рассылать информацию.
Botmother
Где найти:
https://botmother.ru/
Стоимость
: есть бесплатный Тестовый тариф с ограничениями и платные тарифные планы от 4399 ? в месяц.
Более сложный конструктор с множеством различных функций, таких как автоматические ответы, кнопки для взаимодействия с пользователем, а также интеграция с внешними сервисами и базами данных. Программа предлагает интуитивно понятный интерфейс и множество инструментов для настройки ботов под конкретные потребности.
Bottap
Ссылка на конструктор:
https://bottap.ru/
Стоимость
: тарифы начинаются от 99? в месяц.
Здесь создаются боты для Telegram, WhatsApp, Viber и другие. Платформа предлагает готовые шаблоны и инструменты для быстрого запуска ботов с различными функциями: от автоматических ответов до управления заказами и проведения опросов. Для создания алгоритмов необходимо выбирать и передвигать смысловые блоки. Бота можно интегрировать с CRM-системой для бронирования или покупок.
Puzzlebot
Ссылка на конструктор:
https://puzzlebot.top/
Стоимость
: бесплатно, но с ограничениями, стоимость платной версии начинается от 632? в месяц.
Платформа подходит для сложных ботов. Алгоритмы создаются с помощью конструктора. Можно настраивать публикации, собирать посты в сценарии, обрабатывать статистику и многое другое, в зависимости от требований и ресурсов. А в личном кабинете можно легко разобраться, так как на сайте прикреплена подробная пошаговая видеоинструкция.
Что дальше?
Создать простого бота можно без навыков программирования. Мы сами убедились, что различные сервисы предлагают интуитивно понятные программы бесплатно или за невысокую стоимость. Да, в большинстве случаев вы создадите лишь простой помощник, который будет выполнять четко заданные команды. Но с другой стороны, это отличная возможность протестировать, насколько вам в принципе интересно этим заниматься.
В данной статье расскажем про полезные инструменты, которые стали доступны в 4 версии графического интерфейса Elastix. Модуль, который управляет всеми этими инструментами так и называется Tools.
Итак, для того, чтобы попасть в модуль нужно проделать следующий путь PBX → Tools, как показано ниже:
Как видно, нам доступно 5 функциональных инструментов:
Asterisk-Cli
Asterisk File Editor
Text to Wav
Festival
Recordings
Давайте обо всём по порядку.
Asterisk-Cli
Данный функционал избавляет нас от необходимости подключаться к нашей IP-АТС Asterisk по SSH или Telnet для доступа к командной строке, позволяя вводить необходимые команды прямо из web-интерфейса Elastix. Например, может понадобиться для перезагрузки Asterisk или всей системы целиком, просмотра логов, включения режима отладки и т.п.
Ниже представлен пример выполнения команды dialplan show (просмотр правил маршрутизации)
Asterisk File Editor
Позволяет в реальном времени просматривать и менять содержимое конфигурационных файлов Asterisk. Стоит отметить, что при изменении некоторых конфигурационных файлов, Asterisk требуется перезапустить. Для этого предусмотрена отдельная кнопка Reload Asterisk
Text to Wav
Очень простой функционал Text-to-Speech. Пишем в строку нужную фразу, выбираем формат WAV или GSM и жмём кнопку Generate Audio File. Доступен только на английском языке.
Festival
Включаем и выключаем поддержку модуля Festival
Recordings
Данный функционал позволяет быстро добавить звуковую запись в модуль System Recordings. Доступно два способа:
Первый – проассоциировать внутренний номер с аккаунтом пользователя, с которого вы зашли в web-интерфейс, дать записи имя и нажать Record. Через некоторое время, АТС совершит вызов на указанный номер, после короткого звукового гудка – начнётся запись и завершится, когда вы положите трубку.
Второй – загрузить звуковой файл самостоятельно с компьютера.