Что такое крок файлы

Интегрированный стенд разработки КРОК для 1С и не только

Опыт разработки, накапливаемый на крупных и сложных проектах, воплощается в полезные инструменты и инженерные практики, которыми необходимо обогащать процессы разработки, переосмысливая его целиком раз за разом. Именно осознание ценности приобретенного опыта как артефакта, желание развиваться, привело нас к пониманию необходимости внедрения инструментов и практик в текущие процессы. И мы запустили кардинальный пересмотр подходов к проектированию решений и к процессу разработки в целом. Нет смысла описывать типичные ограничения и недостатки «классического» подхода к командной разработке в мире 1С. На эту тему уже много сказано. Опишу лишь паттерны, которые позволили нам сделать эти недостатки маленькими и почти не страшными.

Итак знакомьтесь, интегрированный стенд разработки!

Общие принципы архитектуры

Проектируя архитектуру стенда, мы стремились охватить весь жизненный цикл внедряемых на проектах решений, имплементировать приобретенный опыт, стандартизировать процессы, автоматизировать рутину. При этом, нужно было заложить потенциал развития, сохранить способность к масштабированию и максимальную простоту, с точки зрения обслуживания, развития и работы пользователей. Инструменты и методики, которые доказали свою эффективность на практике, должны добавляться в процесс. А все бесполезное, мешающее в работе, должно быть удалено.

Процесс

Жизненный цикл любого решения практически не меняется в зависимости от масштаба и сложности проекта. Он включает в себя: анализ, проектирование, разработку, тестирование, внедрение, сопровождение, вывод из эксплуатации. Чтобы получить максимальную эффективность, каждый из этих процессов должен быть выверен и согласован с предшествующими и последующими процессами, объединен в подобие автоматизированного конвейера, который может тиражироваться под неограниченное количество проектов. Решить поставленную задачу, позволила реализация системы в виде связанных через экспортируемые API микросервисов в изолированных контейнерах, которую возможно развернуть как в облачном сервисе, так и в локальной сети предприятия.

Вот так выглядит наш стек, реализующий процесс:

Мы постарались свести к минимуму использование платных сервисов с закрытым исходным кодом, что положительно отразилось на стоимости владения. Практически все сервисы с открытым исходным кодом и работают на ОС Linux.

Процесс построен так, что мы получаем максимальную отдачу от каждого члена команды разработки, а стандартизация и автоматизация избавляют от чрезмерной сложности и рутины.

Проектирование (Сервис Проектирования Прикладных Решений)

Один из наиболее значимых этапов при старте проекта — проектирование будущего решения на основе анализа требований. Основная задача — максимально понятно, однозначно и быстро описать архитектуру будущего решения, в терминах понятных как разработчику/инженеру, так и консультанту. Описать метаданные, алгоритмы реализуемых бизнес-процессов. При этом, хотелось максимально задействовать готовые, быстро настраиваемые под конкретные условия шаблоны, которые можно адаптировать к данным на входе и получить проектную документацию на выходе.

Мы внедрили конфигурацию «1С: СППР» в качестве единого интерфейса для проектирования прикладных решений, значительно переработали концепцию описания бизнес-процессов и функций, а также проектирования ТП (ФДР). Еще автоматизировали процессы генерации документации через интеграцию с функционалом «1С: ДО» и микросервисами по генерации документов формата docx.

«1С: СППР». Редактирование информации о проекте:

«1С: СППР». Отчёт по процессам:

«1С: СППР». Редактирование метаданных объектов:

«1С: СППР». Редактирование схемы бизнес-процесса:

Кстати, мы можем визуализировать взаимосвязь между бизнес-процессами и объектами в системе, сформировать список доработок на основе зарегистрированных требований и получить проектную документацию автоматически, что упрощает процесс управления изменениями. А значит, детально спланировать процесс разработки, видеть сложность, связанность задач, точнее определять сроки и порядок их реализации.

Конечно, нельзя сказать, что процесс проектирования изменился кардинально, однако унификация организационных подходов и автоматизация многих функций уже вносит вклад в качество проектов.

Разработка (Сервисы непрерывной интеграции, инспекции и тестирования)

Мы постарались сфокусироваться на возможности всестороннего, непрерывного, автоматизированного контроля качества разрабатываемого кода, чтобы гарантировать соответствие установленному в КРОК стандарту. Причем, даже если привлекаем сторонние команды разработчиков, методики, инструменты и стандарты разработки которых могут существенно отличаться от принятых у нас.

На стенде каждый коммит разработчика автоматически запускает процедуру разбора конфигурации в структуру каталогов и файлов через сервис Gitsync. Полученные изменения индексируются и помещаются в репозиторий Git. В нашем случае это сервис Gitlab. Сообщение коммита автоматически формируется из текста комментария, введенного при помещении изменений в хранилище конфигурации, а автор коммита в системе контроля версий сопоставляется с пользователем хранилища конфигурации. Во время разбора из текста комментария мы можем получить информацию о задаче разработки и трудозатратах, передать ее системе отслеживания задач, например, Jira. Это дает исчерпывающую картину истории разработки. Например, мы можем найти автора по строке кода, а smart-комментарии к коммитам позволяют управлять автоматически статусами задач и оценивать код в привязке к задачам непосредственно в самих задачах.

Gitlab. Теперь возможно прокомментировать любую строку помещаемого коммитом кода:

Gitlab. Провести «Code Review» c подсветкой синтаксиса:

Gitlab. Получить наглядную картину изменений кода в новом коммите:

После каждого коммита в репозитории автоматически запускается процедура статической инспекции кода сервисом SonarQube. BSL код коммита проверяется на соответствие набору правил (профиль качества), описывающих стандарт разработки кода. Процедура выполняется как для кода разрабатываемой конфигурации, так и для внешних механизмов: расширений, внешних отчетов и обработок и, в принципе, любого другого кода проекта, даже на других языках.

SonarQube:

Каждая проверка обновляет информацию отслеживаемых метрик качества кодовой базы, таких как:

Собранные в результате проверки метрики дают наглядное представление о текущем состоянии кодовой базы проекта, позволяют оценить качество, выявить риски, оперативно исправить ошибки.

Профиль качества может расширяться собственными наборами правил через XPath, а также за счет выпуска новых правил в составе собственной реализации плагина для языка 1С. Это позволяет гибко управлять требованиями качества, исходя из реалий конкретного решения.

Автоматизированный запуск процессов разбора конфигурации, инспекции кода, автоматизированного тестирования и т.д. запускает сервис непрерывной интеграции (сервис Jenkins). Количество и характер таких сборочных линий может быть изменено в соответствии со спецификой того или иного проекта.

Несмотря на относительную сложность описанного процесса, все механизмы конвейера, которые выполняют рутину, скрыты в облачном сервисе. А разработчик имеет дело с привычным для него интерфейсом конфигуратора, а также может развивать свои навыки, используя более продвинутые инструменты. Например, git, репозиторий для внешних механизмов в связке со сторонними редакторами кода и SonarLint, SourceTree, и т.п.

В общем случае разработчик подключает информационную базу к сервису хранилища конфигурации 1С, пишет код и помещает его в этот сервис, тем самым запуская скрытый от него процесс на стенде. Если в результате проверки коммита в коде выявлены недостатки, разработчик получает почтовое уведомление (или сообщение чат-бота) со ссылкой на описание ошибки и с рекомендациями по исправлению и временной оценкой трудозатрат в интерфейсе сервиса SonarQube. После исправления ошибки, происходит новый коммит и процесс повторяется, отредактированные задачи автоматически закрываются… технический долг уменьшается. По той же логике построен процесс автоматизированного тестирования, где каждый коммит инициирует запуск развёртывания тестового окружения, подключает необходимые тесты из библиотеки тестов. А после прогона агрегируется информация об ошибках при тестировании, а также о покрытии кода тестами.

Трудно переоценить эффект от непрерывной, всесторонней проверки кода, за которой следует автоматизированное тестирование разрабатываемого функционала. Это позволяет избавиться от далеко идущих последствий, сделать этапы разработки прозрачными, а вкупе с правильно выстроенными процессами, объективно оценить квалификацию разработчиков, что исключает риски зависимости от подрядчиков. Оценивая параметры текущей кодовой базы, мы можем оперативно выявлять и нивелировать возникающие риски, исправлять недочеты проектирования, своевременно реагировать на меняющиеся требования.

Модульная организация архитектуры стенда позволяет встраивать в процесс новые модули, тиражировать решение для необходимого количества проектов. Схематически она выглядит так:

Тестирование (сервис непрерывного тестирования)

Выше я уже говорил про сервис непрерывного тестирования, который интегрирован в конвейер процесса разработки. На данный момент на стенде реализован прогон дымовых тестов и unit-тестов. Функционал автотестов реализуется с использованием фреймворка xUnitFor1C.

Запуск процессов тестирования, так же как инспекция кода, привязан к событию коммита в репозиторий проекта. Для unit-тестов подразумевается разработка теста параллельно с разработкой функционала. Непосредственно перед их выполнением производится автоматизированное развертывание последней версии конфигурации в подготовленную тестовую информационную базу. Затем запускается клиент, который выполняет сценарии тестирования для уже реализованного функционала. Тесная интеграция сервисов автоматизированного тестирования с BSL плагином SonarQube позволяет вычислить такой параметр как покрытие кода тестами. Результат прогона тестов — отчет, который загружается в систему анализа и визуализации результатов тестирования ReportPortal. Этот сервис представляет собой портал отчетов, в котором агрегируются данные о прогонах тестов (статистика и результаты), производится базовое обучение системы по категоризации падений и дальнейшее автоматическое определение причин. Все параметры прогонов тестов доступны в удобном веб-интерфейсе с различными досками для графиков, диаграмм (виджетов). Для расширения функций портала возможно использовать собственные расширения.

Сервис автоматизированного тестирования — это еще один этап, снижающий риски попадания в релиз кода, который ломает ранее реализованной функционал или работает с ошибками.

ReportPortal. Дашборд:

ReportPortal. Неудачные запуски тестов:

ReportPortal. Типы дефектов:

ReportPortal. Редактирование типов дефектов:

Развитие

Оценивая результаты проделанной работы, мы видим, что из задуманного уже реализовано, какие идеи уже успешно работают, какие еще только предстоит реализовать.

Из планов на ближайшую перспективу развития стенда — создание портала управления сервисами стенда. Веб-интерфейс портала позволит работать с заявками на подключение проектов к стенду, с калькулятором стоимости сервисов, с их автоматизированным развертыванием по запросу под проект. В результате менеджер сразу же может получить калькуляцию стоимости выбранных услуг и оценить затраты, определить разработчиков на проект.

Мы планируем провести интеграцию портала с облачным решением эксплуатации систем 1С. Это поможет быстро разворачивать тиражируемые типовые решения в связке с сервисами разработки, реализованными на стенде для более эффективной миграции систем заказчика в облако КРОК.

Портал управления планируем также интегрировать с сервисом автоматизированного управления конфигурацией (развертывание, настройка, удаление). Это позволит сократить время развертывания, упростить настройку и обслуживание системы. А для повышения уровня безопасности внедрим сервис сквозной аутентификации по всем сервисам стенда, чтобы использовать одну и ту же учетную запись во всех из них.

Если рассматривать весь процесс с точки зрения истории полного цикла разработки решения, то созданный конвейер позволит собрать и агрегировать большое количество разнообразных метрик как по артефактам проекта, так и по специалистам, которые принимали в нем участие. Такая подробная ретроспектива будет способствовать накоплению и повторному использованию опыта в решении сложных задач, формировать команды из успешных разработчиков для более эффективной и слаженной работы.

UPD. По просьбам в комментариях добавляем список опенсурсных продуктов, которые используем, с ссылками.

Источник

КРОК — первый сертифицированный поставщик облачных услуг Red Hat в РФ

У нас тут небольшой праздник. Red Hat, Inc. (NYSE:RHT), компания, которая делает довольно известный софт с открытым исходным кодом, присвоила нам статус сертифицированного поставщика облачных услуг. Мы получили этот статус по трем причинам — во-первых, поскольку мы российский лидер в области создания ИТ-инфраструктур и системной интеграции, во-вторых, мы соответствуем требованиям Red Hat к построению публичных «облаков» (в том числе и нашего публичного «облака»), и в-третьих, потому что уже давно и тесно дружим с *nix-экосистемой.

Что это значит?

Участие в программе предоставляет КРОК возможность оказывать облачные услуги корпоративного класса с использованием ПО Red Hat. Официально, круто и хоть в госучреждениях. Это очень важно. Мы можем официально поставлять заказчикам продукт Red Hat Enterprise Linux.

Как давно мы стали красноглазиками?

С Red Hat мы сотрудничаем уже около 10 лет. Делали несколько совместных проектов для крупных российских компаний. Из самого большого — наш Виртуальный дата-центр, состоящий из двух физических ЦОДов. В нём сейчас чуть более 50 весьма крупных организаций.

Что означает этот статус?

Что мы делаем публичные «облака» в соответствии с требованиям Red Hat к построению публичных «облаков». В первую очередь это касается нашего собственного крупного публичного B2B-облака, с которым работает банковская, энергетическая, страховая, медицинская, телеком-сфера, розница и так далее. Главный приоритет — надёжность и безопасность. Поэтому — Red Hat и опенсорс.

Почему именно шапка?

Red Hat — это открытый код и решения корпоративного класса. На эту экосистему очень просто переносить новые приложения, очень легко конфигурировать без костылей и так далее.

Что в планах?

Продолжим оказывать заказчикам услуги из нашего «облака» на базе решений Red Hat, будем наращивать компетенции в строительстве гибридных «облаков».

Насколько сложно получить такой статус?

Делается тщательная проверка. Каждый партнер должен выполнить тестовые и сертификационные требования, чтобы продемонстрировать возможности по предоставлению безопасной масштабируемой, поддерживаемой и совместимой среды для развертывания корпоративных «облаков». Программа Red Hat для сертифицированных поставщиков — это достаточно серьёзное доказательство надёжности.

Источник

Облако КРОК

Серверная инфраструктура и программно-определяемое хранилище Облака КРОК построено на базе решений Dell Technologies.

КРОК предоставляет виртуальные машины с широкими возможностями по масштабированию (до 384 ГБ RAM) и размещением в двух распределенных ЦОДах. Они имеют высокую доступность по умолчанию — в случае отказа оборудования все ВМ перезапускаются на свободных серверах платформы.

КРОК также предлагает виртуальные машины с уже предустановленным системным и прикладным ПО Microsoft, Cisco, SAP HANA, Red Hat, Citrix, Oracle — данное ПО предоставляется в рамках программ подписки от соответствующих производителей.

Облако КРОК предоставляет на выбор два типа виртуальных дисков — «Универсальный» и «Флеш». Каждый из них имеет свои особенности и предназначение:

«Универсальный» подходит для загрузочных дисков или для приложений, которые не требовательны к производительности и времени отклика дисковой подсистемы. Диски большого объёма имеют хорошую производительность линейного чтения и записи и могут использоваться для процессинга логов, больших данных (big data), стриминга.

Max (MB/s) = Size (GB) * 0,25 (MB/s per GB), но не менее 8 MB/s.

При увеличении диска максимальная пропускная способность увеличивается автоматически.

«Флеш» — когда нужна гарантированная высокая производительность и низкое время отклика (latency). Хорошо подходит для высоконагруженных баз данных, тяжёлых веб-приложений.

Общие особенности подсистемы хранения данных:

В качестве среды передачи данных используется высокоскоростная 56 GB/s InfiniBand фабрика. Все виртуальные диски поддерживают:

В Облаке КРОК фундаментом сетевых сервисов является Virtual Private Cloud (далее — VPC). Это аналог VRF (Virtual Routing and Forwarding) на «классическом» сетевом оборудовании. VPC предоставляет сетевую изоляцию — отсутствует IP-связанность между разными VPC по приватным адресам. Помимо изоляции, VPC предоставляет различные сетевые сервисы, о них далее.

Все подсетиодного VPC автоматически имеют IP-связанность. Используя подсети, вы можете разделить IP-пространство VPC на множество L3 сегментов. Кроме того, можно создать подсети с указанием AZ (Availability Zone), в которой будет расположена подсеть. Таким образом можно распределить сервисы между разными AZ так, чтобы снизить влияние инцидентов в какой-либо AZ.

Вы можете аллоцировать из публичного IP пространства Облака КРОК случайный адрес и назначить его на любой экземпляр. При необходимости этот адрес можно переназначить на любой другой экземпляр вне зависимости от его расположения в подсетях и AZ. Такие ассоциации адресов работают при помощи технологии Static NAT.

Для подключения удаленной площадки или соединения со сторонним публичным Облаком, вы можете настроить IPSec VPN. В таком случае нет необходимости в самостоятельной настройке и обслуживании VPN на экземплярах в Облаке.

Вы можете разместить свое оборудование в любом из ЦОД компании КРОК, либо арендовать внешний канал связи и подключить его к виртуальной инфраструктуре в Облаке. Для этого инженеры КРОК подключат ваше оборудование к оборудованию Облака. Далее вы самостоятельно можете подключать эту внешнюю сеть к любой подсети Облака в консоли управления, либо через API. Мы поддерживаем подключения на скорости до 10Gbit/s.

Безопасность

Для разграничения сетевого доступа между подсетями VPC, а также внешними ресурсами, вы можете создавать egress/ingress правила с указанием IP источника/назначения, протокола, порта и приоритета. Network ACLs работают в stateless режиме — возвратный трафик должен быть явно разрешен.

Еще один вид встроенного в Облако firewall. Вы можете создавать логические контейнеры, в которые добавляются разрешающие правила с IP по протоколу и порту. Если в Security Group нет правил, весь трафик запрещён. Эти правила отрабатывают в stateful режиме — вне зависимости от того, есть ли у Вас разрешающие правила для возвратного трафика — он будет разрешен. Кроме того, помимо IP в правилах Security Group вы можете указывать другие Security Group.

Прочие сетевые сервисы

Каждый экземпляр в Облаке автоматически получает сетевую конфигурацию по DHCP. Вы можете управлять некоторыми параметрами, например, dns-servers, ntp-servers, domain-name и пр.

Каждое VPC имеет встроенный DNS-резолвер, который разрешает внутренние имена экземпляров, а также все публичные имена.

Для управления маршрутизацией трафика во внешние сети, сети VPN или сети, располагающиеся за экземплярами, вы можете управлять таблицей маршрутизации VPC. Также можно создавать разные таблицы маршрутизации и ассоциировать их с разными подсетями, тем самым реализовывая source-based routing.

Когда вы захотите соединить экземпляры в разных VPC, либо вам потребуется дополнительный интерфейс в экземплярах, можно создать виртуальный коммутатор и подключить его к экземплярам «на горячую». Это L2 сеть, которая не имеет внутри никаких дополнительных сервисов помимо сетевой связанности между экземплярами, находящимися в ней.

Источник

Диски¶

Общая информация¶

Виртуальный диск в Облаке КРОК является основным хранилищем данных экземпляра.

Все диски подключаются по эффективному протоколу VirtIO, поэтому для работы с ними требуется специальная поддержка со стороны операционной системы. Все официально поддерживаемые Облаком КРОК образы операционных систем уже содержат необходимые драйверы.

При создании экземпляра, с помощью опции Удалить вместе с экземпляром, можно указать, должен ли удалиться диск при удалении экземпляра. Если данная опция для диска не выбрана, или если диск был подключен к экземпляру после его создания, то такой диск при удалении экземпляра будет от него отключен и доступен для подключения к другому экземпляру.

Каждый новый диск является пустым или является копией эталонного образа — образа диска. Эталонные образы чаще всего применяются для загрузочных дисков и содержат установленную и настроенную операционную систему. Размер диска, созданного из эталонного образа, может превышать размер эталона. В данном случае, на диске появляется дополнительное пустое пространство. Впоследствии можно создать дополнительный раздел или увеличить размер файловой системы, чтобы она заняла весь диск.

Каждый диск обладает набором параметров:

ID – уникальный идентификатор диска.

Состояние – содержит информацию о состоянии диска.

Зона доступности – содержит информацию о расположении физического оборудования.

Тип – указывает тип диска.

Размер – максимальный объём данных, который способен вместить диск.

Типы дисков¶

Облако КРОК предоставляет пользователям несколько типов дисков, отличающихся характеристиками, возможностями и стоимостью. В таблице представлены примеры использования и основные характеристики типов дисков. По умолчанию при создании экземпляра и диска выбран тип st2.

Недорогой HDD диск для задач, связанных с хранением больших объёмов данных. Диски большого объёма имеют высокую пропускную способность

Универсальный SSD диск, обладающий высокой производительностью и подходящий для широкого спектра задач

Диск SSD с самой высокой производительностью, предназначенный для самых требовательных к IOPS приложений

Хранение больших объёмов данных

Задачи с последовательной записью

Другие задачи с большими размерами данных, используемых в операциях ввода‑вывода

Инфраструктуры разработки и тестирования

Другие задачи, для которых необходима высокая производительность (IOPS, МиБ/с) и низкие задержки

Критичные бизнес-приложения, требующие высочайшую производительность в IOPS

Базы данных с большим количеством операций ввода‑вывода, такие как: MongoDB, Cassandra, MS SQL Server, MySQL, PostgreSQL, Oracle

Максимальная производительность диска, IOPS

Максимальная пропускная способность диска, МиБ/с

Источник