По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через 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.
Чтобы понять NoSQL, нужно разобраться, что такое SQL и почему мы говорим ему No.
Итак, SQL (structured query language) расшифровывается как «язык структурированных запросов», и это язык запросов для управления данными в так называемых реляционных базах данных, или просто БД
В реляционных базах мы храним данные в таблицах, которые логически связаны между собой - отсюда и название - реляционные от слова relation, связь. Это один из самых популярных типов баз.
В этих таблицах есть строки и столбцы. В столбце таблицы хранится определенный тип данных, а в каждой ячейке – значение.
Строка же получается как набор связанных значений, которые относятся к одному объекту - мы видим что у крыла типа чайка длина 25 метров.
Ну и каждая строка в таблице может быть помечена каким то уникальным идентификатором, который называется первичным ключом (primary key). А затем при помощи него мы можем связать данные из нескольких таблиц, например в отдельной таблице, где он станет внешним ключом (foreign key).
В общем, как таблица в экселе, только данные могут быть связаны.
Что еще важно знать: реляционные БД требуют так называемую схему (schema) - описание структуры таблицы ее полей и ограничений. То есть если нам например нужно добавить или убрать столбец в таблице, то это изменение коснется всех данных внутри нее.
Также БД этого типа соответствуют так называемым принципам ACID (Atomicity — Атомарность, Consistency — Согласованность, Isolation — Изолированность, Durability — Надёжность), что вкратце означает, что при работе с базой, целостность и согласованность данных гарантирована, даже если возникли проблемы с сетью или железом, что полезно при работе с финансами, например.
В качестве примеров таких баз назовем: Microsoft SQL Server, Oracle Database, MySQL и PostgreSQL.
Разобрались. Теперь вернемся к NoSQL. Это тип баз данных, которые хранят данные в отличном от реляционных таблиц формате. Они узкоспециализированны для конкретных задач и нужны для улучшения производительности, масштабируемости и удобства в работе.
Базы данных "ключ-значение" (key-value)
Суть в том, что мы храним данные в таком виде: у нас есть уникальный ключ, который указывает на какое-то значение. А сама база - это совокупность этих пар. Вот так просто! Причем эти данные могут быть чем угодно, числом, строкой или даже другой парой ключ-значение потому что в отличии от реляционных баз данных они не имеют предопределенной структуры данных.
Многие БД такого типа хранят данные в памяти (RAM), в отличии от других баз, которые хранят данные на диске, что хоть и может ограничивать объем хранимых данных (хотя они требуют гораздо меньше памяти), но это обеспечивают просто невероятную скорость. Ну и раз это NoSQL то никаких сложных запросов, никаких связей друг с другом - мы просто записываем ключ и его значение, и получаем значение по ключу.
Где их использовать? Они отлично подходят для хранения кэша или пользовательских сессий. А в качестве самого простого примера можно назвать корзину в интернет магазине - где мы храним идентификатор пользователя, и сколько товаров он положил в корзину.
Самые популярные хранилки по типу “ключ - значение” это Redis, Memcached и DynamoDB.
Wide-column (columnstore базы данных, БД с широкими столбцами или колоночные БД)
Все также просто - берем key-value БД, и делаем так чтобы в значении мы могли хранить несколько столбцов сразу. Это позволяет удобно хранить связанную информацию. Похоже на реляционную БД, но только в отличии от нее, тут у нас нет схемы, поэтому мы можем хранить разные неструктурированные данные.
Такой тип БД подойдет для хранения логов, данных с умных холодильников и чайников, а также различных аналитических приложений, где данные хранятся в большом объеме. Netflix, например, хранит в таких таблицах историю просмотров пользователя.
В качестве примеров таких баз назовем Cassandra, Hbase и ClickHouse.
Базы данных документов или документориентированные БД (Document DB)
Подробнее про них можно прочитать в нашей отдельной статье.
Если предыдущие типы NoSQL БД обычно используются для специфических задач, то эти базы уже более универсальны, и могут стать основным местом хранения информации.
Здесь мы храним документы. Документ это набор нескольких пар ключ-значение, о которых мы говорили раньше, и раз это не SQL, то они неструктурированны и не требуют схему. Это значит, что мы можем легко добавлять и удалять поля в документе, в отличие от реляционных БД, где изменения затронули бы всю таблицу. Документы даже могут быть вложенными, и содержать в себе другие документы.
Данные хранятся в стандартных форматах, таких как XML, YAML и JSON. Такая форма хранения идеально подходит к объектам, которые используются в приложениях. Мы буквально сразу получаем полный объект который нам нужен, а в SQL нужно сначала приложить усилия и даже сделать несколько запросов и все собрать в необходимый вид.
Документы можно группировать друг с другом собирая их в коллекции, которые можно собирать в логическую иерархию, получая что-то по типу реляционных БД.
Это как шкаф на работе - в один ящик мы можем положить трудовые договоры, в другой - договоры с партнерами, а в третий договоры аренды.
Ничто нам не мешает сложить всё в одну кучу, но так удобнее. И вот эти ящики как раз и будут коллекциями в нашем случае. А отсутствие схемы позволяет нам положить в один ящик договоры, которые схожи логически, но имеют разную структуру внутри. Например, долгосрочный договор с сотрудником и договор с компанией. Коллекции есть не у всех БД такого типа, некоторые системы используют теги или древовидные иерархии.
Они часто используются для мобильных приложений и игр, блогов, интернет магазинов и всяких штук где у нас имеется много контента.
Самые популярные БД такого типа - MongoDB, Amazon DynamoDB, CouchDB.
Графовые БД (Graph DB)
Тут мы больше значения уделяем тому как данные связаны друг с другом, и эта БД лучше всего обрабатывает такие данные.
Тут у нас есть узлы, которые представляют данные и ребра (или соединения), которые описывают связь между этими данными. Помните как в реляционных базах мы записывали связь в отдельной таблице? Тут мы можем обойтись без нее, просто показав связь.
Такие базы просто необходимы для алгоритмов рекомендаций, социальных сетей, управления компьютерными сетями и маршрутизацией или даже обнаружения финансового мошенничества.
Самые популярные графовые базы: Neo4j и DGraph
Поисковые БД (Search-engine database)
Они, как понятно из названия, нужны для поиска данных из большого количества источников.
Работают они примерно также как и базы данных документов - мы добавляем документы с текстом внутри, а БД проанализирует весь текст в этих документах и создаст индексы для этого текста.
По сути это работает как указатели, которые ты видел в конце книги, где указывается какой-то термин и страница на которой он встречается.
И когда пользователь выполняет поиск, то сканируются только эти индексы, а не все документы в базе.
Ну и очевидно что они используются в качестве полнотекстового поиска, а также для хранения и анализа логов. Примеры - Elasticsearch, Solr, Algolia
Базы данных временных рядов (Time series database)
Это базы данных, оптимизированные для данных с отметками времени. Такое используется, для мониторинга систем, где мы храним значение времени и данные в этот момент. Например, загрузка сервера или количество подключений.
Примеры - InfluxDB и Prometheus
Многомодульные БД (multi-model)
Также существуют так называемые много-модульные БД (multi-model), которые поддерживают несколько моделей данных.
Например тот же рredis умеет и в ключ-значение, и документы с графами и даже временные данные обработает.
Привет! Сегодня в статье мы покажем, как собирать трейсы с Cisco Unified Communications Manager (CUCM) . Это используется для траблшутинга системы, а так же эта информация будет необходима TAC инженерам Cisco при заведении заявки.
Для того чтобы снять трейсы нам понадобится программа Real-Time Monitoring Tool. О том как ее установить можно прочитать в нашей статье.
Сначала идем в меню Cisco Unified Serviceability, и переходим во вкладку Trace → Configuration. Здесь выбираем наш сервер, в строке Server, в строке Service Group выбираем CM Services, а в строке Service указываем Cisco CallManager. Дефолтные настройки показаны на скриншоте.
Убедитесь, что галочка стоит в пункте Trace On, а в выпадающем меню Debug Trace Level выбран пункт Detailed.
Тоже самое нужно повторить на других серверах кластера, если они имеются.
Далее запускаем RTMT и подключаемся к нашему серверу. Тут переходим во вкладку System → Tools → Trace & Log Central. Нажимаем Collect Files и в открывшемся окне ставим галочки в строке Cisco CallManager выбрав необходимые сервера.
Нажимаем Next и в следующем окне ставим галочки в пунктах Event Viewer → Application Log и Event Viewer → System Log.
Далее необходимо выбрать временной промежуток снятия наших данных в поле Collection Time. В этом же окне, в поле Download File Options указываем папку, в которою все будет скачиваться.
Теперь можно нажать Finish и после сбора информации нужные нам файлы окажутся в указанной ранее папке.