По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
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.
img
Было время, когда все, что связано с установкой, конфигурацией, обслуживанием инфраструктуры, выполнялось вручную. Для одной работы привлекались много сотрудников. Все было вручную. Этот процесс имел значительный риск человеческих ошибок, что приводило к понижению доступности, безопасности и производительности приложений. Не стоит забывать и общую стоимость инфраструктуры. Но благодаря современным технологиям и философии, таким как DevOps, это больше не проблема. Теперь у нас есть несколько инструментов для выполнения задач создания, развертывания и управления инфраструктурой. Используя правильное программное обеспечение, можно автоматизировать всю инфраструктуру приводя участие человека к минимуму. Я говорю не о простых вещах, а о сложных задачах, таких как выделение ресурсов инфраструктуре, полная настройка приложений и т.д. Автоматизация инфраструктуры - это процесс развертывания аппаратных/программных компонентов, операционной системы, сетевых компонентов, компонентов хранения данных с использованием IaC (Infrastructure as Code). Этот процесс имеет вмешательство человека только для написания такого кода, который будет иметь все детали для создания и развертывания необходимых компонентов. Вот список наиболее популярных средств автоматизации инфраструктуры, широко используемых в отрасли. 1. Ansible Ansible - это ядро с открытым исходным кодом, который автоматизирует развертывание приложений, управление конфигурацией, организацию ИТ. Основана в 2012 году и написана на самом трендовом в настоящее время языке - Python. Для реализации всей автоматизации Ansible использует плейбуки, где все конфигурации написаны на удобочитаемом языке - YAML. Anible имеет безагентную архитектуру, то есть не нужно устанавливать какое-либо программное обеспечение отдельно на всех серверах. Он следует модели на основе push, где необходимо иметь локальную систему со всеми необходимыми конфигурациями, и эти конфигурации перемещаются на целевые серверы. Доступные функции: Автоматизация с помощью простого удобочитаемого языка; Безагентная архитектура позволяет подключаться к серверам через обычный SSH; Модель push передает конфигурации на сервер с локальной машины, управляемой вами. Построен на Python, поэтому поддерживает множество библиотек и функциональных возможностей данного скриптового языка; Кураторская коллекция модулей Ansible инженерной команды Red Hat. Для больших предприятий Red Hat предлагает Ansible Tower. 2. SaltStack Stack может с высокой скоростью выполнять управление инфраструктурой, управление конфигурацией и оркестровку. По сравнению с другими подобными инструментами, такими как Chef и Puppet, быстрота SaltStack является существенным отличием. Данное решение было представлено в 2011 году, и так же, как и Anible, он написан на Python. Он имеет архитектуру master-slave, где Salt Master является главным демоном, который управляет всем, а Salt Minions являются подчиненными демонами, установленными на каждой управляемой системе для выполнения команд, отправленных Salt Master. Salt Master отправляет необходимые настройки и команды Salt Minions, а Salt Minions выполняют их на своей машине, чтобы применить всю IT-автоматизацию. Функции Stack: Рассчитанный на масштаб и скорость, один мастер может работать с 10000 миньонов. Очень прост в настройке, имеет единую архитектуру удаленного выполнения. Файлы конфигурации в Stack поддерживают все виды языков. Он может выполнять команды на удаленных системах параллельно, что помогает ускорить автоматизацию. Предоставляет простой интерфейс программирования с использованием API Python. 3. Chef Одной из основных причин производственных инцидентов является несогласованность приложения или конфигурации. Это обычная проблема, и Chef стремится исправить это. Chef - это инструмент управления конфигурацией для управления инфраструктурой. Он был написан на Ruby, а первый релиз состоялся в 2009 году компанией OpsCode. Продукт Chef Infrastructure Management обеспечивает соответствие всех сред одним и тем же конфигурациям в инфраструктуре. Она предоставляет различные инструменты для управления инфраструктурой вроде Chef Infra, Chef Automate, Chef Enterprise и Chef Community. Функции Chef Infrastructure Management: Конфигурации написаны на языке YAML; Она поставляется с несколькими инструментами разработки для написания книг рецептов (конфигураций), тестирования и разрешения зависимостей; Корпоративная версия предоставляет возможности совместной работы для упрощения обработки сложных сред. Поддержка интеграции с сотнями инструментов DevOps, таких как GitHub, Jenkins, Azure Terraform. 4. Bolt Bolt - один из открытых проектов Puppet. Это безагентный инструмент для автоматизации ИТ. С помощью Bolt можно автоматизировать все задачи, выполняемые вручную, что необходимо сделать сегодня в соответствии с требованиями. Я говорю о таких задачах, как развертывание приложения, устранение неполадок серверов, остановка и перезапуск службы, исправление и обновление систем и т.д. Поскольку Bolt не содержит агентов, нет необходимости устанавливать какое-либо программное обеспечение агента на удаленных целевых машинах. Необходимо установить Bolt в локальной системе и подключить удаленные целевые системы с помощью SSH или WinRM. Основные возможности Bolt: Запишите план болта (сочетание команд, сценариев и задач) в YAML, простой в использовании и изучении. Многие существующие планы и рабочие процессы доступны в Puppet Forge (библиотека модулей). Переместите автоматизацию с Bolt на Puppet Enterprise для лучшей масштабируемости. 5. Terraform Terraform - это средство выделения ресурсов инфраструктуры с открытым исходным кодом, используемое для создания и развертывания инфраструктуры с использованием инфраструктуры в качестве кода (IaC). Hashicorp представила его в 2014 году. Terraform довольно хорошо работает с такими поставщиками облачных технологий, как AWS, Azure, GCP, Alibaba. С помощью Terraform можно развертывать инфраструктуру и управлять ею на любом из этих облачных поставщиков. В настоящее время Terraform широко используется многими организациями для управления Kubernetes кластерами. Преимущества Terraform: Простое управление конфигурацией неизменяемой инфраструктуры. Может выполнять полную оркестровку инфраструктуры, а не только управление конфигурацией. Использует язык конфигурации HashiCorp (HCL), который удобочитаем и очень прост для изучения. Предоставляет готовые модули и провайдеров для сотен инструментов, и технологий через реестр terraform. Заключение Это был мой список самых популярных решений для автоматизации инфраструктуры, которые предлагают продукты для организаций среднего размера на уровне предприятия. Если вы попадаете в домен DevOps и хотите автоматизировать свою инфраструктуру и связанные с ней монотонные задачи, это подходящее время, чтобы выбрать одно из вышеупомянутых решений и начать автоматизацию.
img
Битрикс24 – облачная CRM система, цель которой заключается в повышении эффективности работы компании. Мы можем выделить 3 позиции, которые привлекают внимание предпринимателей к этой системе: Доступность - для начинающих предпринимателей Битрикс24 бесплатна по тарифу «Проект». В бесплатной версии вы можете вести обработку лидов, сделок, ставить задачи, создавать проекты, выставлять счета и многие другие опции. В бесплатной версии нет возможности создавать бизнес – процессы. Более высокие версии, такие как «Команда» или «Компания» обладают более богатым функционалом за привлекательную цену. Омниканальность - вся деятельность по различным каналам работы будет сконцентрирована в Битрикс24. Без разницы, напишет ли клиент письмо на общий адрес электронной почты компании, или на адрес менеджера персонально, напишет в Telegram, Вконтакте, Facebook, заполнит форму на сайте или позвонит – автоматические будет создан лид в CRM и обработан согласно внутренним правилам в зависимости от источника. Гибкость - CRM система имеет приложение для ПК, смартфона и планшета. Важно отметить, что существует специальный REST API, с помощью которого можно создавать лиды с помощью PHP с сайта. Коробочную версию CRM можно дорабатывать с помощью собственных PHP скриптов. Если вы остановили свой выбор на Битрикс24 и ищете возможности автоматизировать обработку лидов, то в статье мы расскажем о интеграции Битрикс24 с сайтом. Интеграция Битрикс24 с сайтом Начнем с создания HTML формы на сайте по примеру ниже: <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <form action="integration.php" method="post"> Тема: <input type="text" name="tema" value="" /><br /> Ваша компания: <input type="text" name="companyname" value="" /><br /> Имя: <input type="text" name="name" value="" /><br /> Фамилия: <input type="text" name="lastname" value="" /><br /> Ваше сообщение: <textarea name="message"></textarea><br /> <input type="submit" value="Send" /> </form> </html> Здесь, методом POST, мы будем передавать параметры в PHP файл, который в свою очередь будет связывать наш сайт с Битрикс24. Скопированную сверху конфигурацию сохраняем в файл, который называем integration.php Продолжаем работу с этим файлом. Над скопированной выше конфигурации открываем PHP – тэг с помощью символов <?php . Между php и вторым знаком вопроса мы будем вставлять последующую конфигурацию. Определяем необходимые для REST API переменные, с помощью которых мы будем определять адрес сервера подключения и параметры авторизации. Заранее создайте в Битрикс24 пользователя с правами на создание и изменение сущностей связанных с лидами. В конфигурации приведены строки с комментариями: // Параметры подключения к вашему облачному Битрикс24 define('CRM_HOST', 'your_domain.bitrix24.com'); // укажите здесь ваш домен в Битрикс define('CRM_PORT', '443'); // порт для подключения. Здесь оставляем все как есть define('CRM_PATH', '/crm/configs/import/lead.php'); // Путь к PHP файлу, к которому будем подлючаться. Здесь оставляем все как есть // Параметры авторизации define('CRM_LOGIN', 'login'); // логин пользователя, которого мы создали для подключения define('CRM_PASSWORD', 'password'); // пароль пользователя CRM Переходим к самому скрипту, который будет заниматься отправкой данных в CRM $tema = $_POST['tema']; //получаем значение полей из формы и записываем их в переменные методом POST $companyname = $_POST['companyname']; $name = $_POST['name']; $lastname = $_POST['lastname']; $message = $_POST['message']; // Начинаем обработку внутри скрипта if ($_SERVER['REQUEST_METHOD'] == 'POST') { $leadData = $_POST['DATA']; // представляем массив $postData = array( 'TITLE' => $tema, 'COMPANY_TITLE' => $companyname, 'NAME' => $name, 'LAST_NAME' => $lastname, 'COMMENTS' => $message, ); // добавляем в массив параметры авторизации if (defined('CRM_AUTH')) { $postData['AUTH'] = CRM_AUTH; } else { $postData['LOGIN'] = CRM_LOGIN; $postData['PASSWORD'] = CRM_PASSWORD; } // открываем сокет соединения к облачной CRM $fp = fsockopen("ssl://".CRM_HOST, CRM_PORT, $errno, $errstr, 30); if ($fp) { // производим URL-кодирование строки $strPostData = ''; foreach ($postData as $key => $value) $strPostData .= ($strPostData == '' ? '' : '&').$key.'='.urlencode($value); // подготавливаем заголовки $str = "POST ".CRM_PATH." HTTP/1.0 "; $str .= "Host: ".CRM_HOST." "; $str .= "Content-Type: application/x-www-form-urlencoded "; $str .= "Content-Length: ".strlen($strPostData)." "; $str .= "Connection: close "; $str .= $strPostData; fwrite($fp, $str); $result = ''; while (!feof($fp)) { $result .= fgets($fp, 128); } fclose($fp); $response = explode(" ", $result); $output = '<pre>'.print_r($response[1], 1).'</pre>'; } else { echo 'Не удалось подключиться к CRM '.$errstr.' ('.$errno.')'; } } else { } В случае, если вы хотите провести «дебаг» соединения и понять в чем могут быть проблемы, в разделе HTML кода добавьте следующий код, который позволит вывести причину неработоспособности: <?php echo $output; Сохраняем все внесенные конфигурации и переходим к тесту. Заполняем WEB – форму: Как результат, в CRM появляется лид: Лид успешно создан в CRM. Для его обработки вы можете создать различные бизнес процессы в разделе «Настройки» -> «Автоматизация». Сам файл скрипта вы можете скачать по ссылке ниже. После загрузки, измените формат файла на PHP: Скачать скрипт интеграции с сайтом
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59