Op!DevOps! 2017

October 21 2017
Москва, Россия
View
To favorites

Алексей Соловьев

Senior DevOps at Positive Technologies

Алексей Буров

Positive Technologies at DevOps Team

Павел Лысов

Ведущий программист at Positive Technologies

Иван Щербинин

Positive Technologies at Релиз-менеджер

Дмитри Мирошниченко

Инженер по автоматизации at Инженер по автоматизации

About event

Topic: IT

Спикеры рассмотрели некоторые технологии и инструменты, поделились планами развития DevOps в компании.

Audience

  • Тимлидам
  • Сетевым инженерам
  • IT Операторам
  • Системным администраторам
  • Разработчикам
Share

Schedule

Show all
Saturday, October 21
Day 1
Get access to all talks
Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Алексей Соловьев

Senior DevOps at Positive Technologies

Использование анализатора кода SonarQube

1. Использование SonarQube в Positive Technologies Соловьев Алексей Программист отдела DevOps asolovyev@ptsecurity.com linkedin.com/in/aasolovyev Черепанов Сергей Программист отдела DevOps scherepanov@ptsecurity.com

2. План доклада • Что такое SonarQube • Для чего нужны анализаторы кода • Принцип работы • Поддерживаемые языки • Что находит • Метрики • Минусы • Профит

3. Что такое SonarQube • Платформа для анализа кода, управления его качеством • Позволяет непрерывно проводить анализ кода • Работает с множеством языков, используя плагины

4. Для чего нужны анализаторы кода • Анализ текущего состояния кодовой базы • Уменьшение количества багов/уязвимостей в будущем • Повышение качества кода

5. Принцип работы

6. Поддерживаемые языки C/C++ ($) ABAP ($) Web JavaScript VB.NET XML C# VB6 TypeScript Java Python Go (SonarQube 6.0 +) COBOL ($) RPG Multilanguage PL/SQL Flex PL/I($) Objective-C PHP Swift

7. Korea 2015 Technological Advantages and Visionary Approach Что находит •Дефекты кода •Уязвимости • код

8. Korea 2015 Technological Advantages and Visionary Approach Что находит

9. Метрики, снимаемые с кода Reliability Оценка надёжности проекта, основанная на встречающихся багах Security Оценка безопасности проекта, основанная на встречающихся уязвимостях Maintainability Оценка поддерживаемости проекта. Для этого применяется оценка технического долга проекта и информация о «плохом» коде в проекте Duplications Предоставляет информацию о повторениях кода, рассматривает повторения строк, блоков кода, а также файлов, в которых встречаются повторения Complexity Оценка сложности проекта, основанная на числе путей исполнения кода. Когда путь исполнения в функции разделяется, сложность увеличивается на единицу Documentation Оценка количества комментариев в коде Issues Предоставляет информацию о количестве проблем, их типе и статусе Quality Gates Итоговая оценка качества проекта. Критерии для прохождения проектом контроля качества можно настроить отдельно для каждого проекта Tests Оценка покрытия кода тестами

10. Метрики

11. Метрики

12. Пример страницы проекта

13. Минусы • Некорректная работа с LDAP-группами • Высокая стоимость плагинов • Отсутствие иерархичности проектов по веткам кода

14. Профит от использования SonarQube за полгода • Повысилось качество нового кода • Найдены старые баги и уязвимости • Сократилось время, затрачиваемое на ревью кода • Повысилась культура написания кода

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Алексей Буров

Positive Technologies at DevOps Team

Инструмент ChangelogBuilder для автоматической подготовки Release Notes

1. Инструмент ChangelogBuilder для автоматической подготовки Release Notes Алексей Буров CI-инженер aburov@ptsecurity.com

2. Содержание 1. Общие понятия 2. Проблемы 3. Решение 4. Побочные положительные эффекты

3. Общие понятия и определения

4. Что есть Продукт • Системный программный продукт (далее просто Продукт) — набор файлов (к примеру, установщики), который непосредственно поставляется Заказчику или Покупателю. • Пакет (компонент) — атомарная единица продукта. Пакет — единица программного обеспечения, которая может быть независимо заменена или обновлена. У каждого пакета собственные: • Команда разработки • Принятый процесс разработки и баг-трекеры • Релизные циклы • Хранилище исходного кода (vcs) • Система сборки

5. Что мы имеем • Коробочная разработка продуктов • Увеличивающееся количество Продуктов • Пакеты (внутренней и внешней разработки) — часть многих Продуктов • Команды что хотят то и творят имеют свободу действий в выборе нужных им технологий и процессов для разработки Пакетов • TFVC, GITLAB — Version Control Systems • YouTrack, TFS, Gitlab, JIRA — баг-трекеры • Нет единого места хранения исправленных багов и реализованных фич по Продукту • Интеграции между системами есть, но не решают все проблемы • Продукт собирается с нуля

6. Проблема Как понять, какие изменения произошли

7. Проблема • Сборка MainProductName 14.1.1000 = MainProductName 14.1.1001

8. Проблемы • Неясно, какие изменения были внесены в Продукт, с учетом изменений всех его Пакетов между сборками • Тестировщикам непонятно, что тестировать, и как определить, что влияет на баги • Иногда одна фича требует внесение изменений в несколько пакетов (в Backend и UI) — нужно удостовериться, что оба пакета были обновлены в сборке • Хочется иметь два разных CHANGELOG: • внутренний • для заказчиков • Нет отображения иерархий Issue — разработчик указывает Task, но не видно какая User Story частично решается благодаря этому Task

9. Решение Инструмент ChangelogBuilder для автоматической подготовки Release Notes

10. Договариваемся с командами Используемые форматы: • anytextbefore_290215_anytextafter • anytextbefore-290215-anytextafter • :РТ-0000 any text after — Youtrack • anytextbefore/РТ-0000 any text after — Youtrack • :TFS-0000 any text after • #290215: Fixed some problem in logging • #290215 Fixed some problem in logging • Bug 123456: done! • Merge branch 'hotfix/92300' into 'release/v13.0' • #dev-654321: good fix

11. Собрать информацию о пакетах При сборке Продукта в CI-сервере нет информации о Пакетах — какие баг- трекеры используются, какие URL до VCS

12. Собираем информацию во время сборки Давай работай Commit с TaskID Сделать сборку Используемые пакеты Дай commit-message State Title, Assignee Что там нового в сборке?

13. Поддерживаемые системы Баг-трекеры (допускается использование нескольких баг-трекеров на один проект): 1. TFS 2. GitLab-issue 3. YouTrack 4. JIRA 5. CustomChangelog — произвольные комментарии в формате MarkDown VCS: 1. Gitlab 2. TFVC

14. Решение

15. Release Notes

16. Release Notes Поиск по пакету или номеру багаПереход между сборками Изменения в одной сборке

17. Release Notes Changelog без Task Новый пакет Ссылки на commit

18. CustomChangelog – git commit –m “На это нет Task в TFS, поэтому changelog{Начиная с данной версии мы стали использовать **RabbitMQ 3.6.0** [подробнее про изменения](https://wiki.example.com/how-to)}”  – git push origin

19. Release Notes Несколько баг-трекеров Иерархия пакетов

20. Release Notes

21. Решение Дополнительные плюшки

22. Дополнительные плюшки 1. Проставление полей/комментариев в баг-трекер системы

23. Дополнительные плюшки 2.Комментарии о задачах и ссылки на сборки в MergeRequest (GitLab) • В какую высокоуровневую User Store входит этот Bug/Task • В какой релиз пойдет этот Task

24. Дальнейшее развитие 1. Сделать Data-Driven Documents (сейчас из yaml генерируется статичный html и дублируется информация) 2. Экспорт в финальный RELEASE_NOTES.html для заказчика или CHANGELOG.md для пуша в git-репозиторий 3. Публикация в opensource-сообщество github.com/devopshq/

25. Итоги 1. Общие понятия • продукт != Пакет • свобода действий у команд 2. Проблемы • непонятно, какие изменения произошли 3. Решение • главное — договориться • база знаний • общая схема работы 4. Побочные положительные эффекты 1. отчитываемся в Task/Bug 2. получаем информацию в MergeRequest

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Иван Щербинин

Positive Technologies at Релиз-менеджер
and 1 more
speaker

Аналитика в проектах - TFS и Qlik

1. Аналитика в проектах: TFS + Qlik Использование Business Intelligence для анализа активностей TFS Павел Лысов Ведущий программист plysov@ptsecurity.com Иван Щербинин Релиз-менеджер ischerbinin@ptsecurity.com

2. Что такое Business Intelligence Зачем он нужен

3. Business Intelligence • Загружай данные • Анализируй • Выгружай отчеты • Планируй

4. Интеграция Как это работает

5. TFS коннектор. Qlik SDK 1. Подключаем коннектор к TFS 2. В TFS в любой коллекции создается запрос с нужными полями, например, User Stories 3. Этот запрос обрабатывается (через выбор запроса в скрипте загрузки) Qlik View/Qlik Sense, который ежедневно забирает все данные по расписанию 4. «Визуализируй это» в песочнице в десктопном приложении (free) или на сервере

6. Применение Qlik Sense для аналитики и инфографики багов

7. Задача аналитики и инфографики багов в рамках релиза • Сбор статистики по багам с широким спектром параметров для анализа • Выявление основных тенденций и проблем в ходе разработки релиза • Выявление тенденций и проблем при сравнении нескольких релизов • Построение плана действий по проблемным областям

8. Типы полей сущности «Bug», используемые для анализа • Даты создания, фикса • Статус • Версия продукта, в которой исправлен баг • Версия продукта, в которой исправляется баг • Команда разработки • Тип бага • Источник возникновения • Причина возникновения бага (категория, детализация) • Причина пропуска в релиз • Планирование к тестовому покрытию, покрытие в тестах

9. Инфографика встроенными средствами баг-трекера TFS Основные проблемы: • Малая кастомизация выводимых графиков и таблиц • Ограничение выводимых значений по шкалам • Отсутствие навигации по данным • Невозможность гибкой дофильтровки данных • Отсутствие гибких инструментов создания сущностей

10. Входные данные для BI на основе Qlik Sense

11. Аналитика и инфографика багов через Qlik Sense: основные элементы

12. Аналитика и инфографика багов через Qlik Sense: основные элементы

13. Аналитика и инфографика багов через Qlik Sense: основные элементы

14. Аналитика и инфографика багов через Qlik Sense: пример использования при анализе Баги по источнику происхождения Баги по разрабатываемой функциональности Баги по причине пропуска в релиз Представление багов в табличном виде

15. Основные преимущества использования Qlik Sense для аналитики багов • Удобная навигация и дофильтрация данных • Красивая визуализация элементов • Широкие возможности по выводу инфографики • Простой механизм сохранения снапшотов листов • Простота создания/копирования/донастройки элементов • Настраиваемый механизм подгрузки данных • Возможность использования в качестве веб-сервера

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Дмитри Мирошниченко

Инженер по автоматизации at Инженер по автоматизации

Методика определения неиспользуемых ресурсов виртуальных машин и автоматизация действий с ними

1. Методика определения неоптимально используемых ресурсов Мирошниченко Дмитрий Инженер по автоматизации dmiroshnichenko@ptsecurity.com

2. Как появилась идея

3. История проблемы 2012 2015 2016 2017 История

4. Проблемы Завис сервис Не стартует VM Сборочный сервер тормозит Кончилось место на сторе ПричинаПроблема Disk, CPU, MEM Disk CPU, MEM Disk

5. Цель разработки Методики 1. Решить проблему постоянной нехватки ресурсов инфраструктуры R&D не путем наращивания машинных ресурсов, а оптимизацией потребления этих ресурсов 2. Подтвердить гипотезу, что значительная часть данных ресурсов используется неоптимально

6. DoD 1. Сформулированы критерии неоптимальности использования ресурсов 2. Разработана методика определения неиспользуемых ресурсов инфраструктруры, без необходимости ручных действий 3. Разработан скрипт, реализующий эту методику, который можно передать вне отдела DevOps

7. Инфраструктура HW HW HW Clouds • Двадцать команд • Десятки проектов • Тысячи VM

8. Первичная оптимизация • Рассылка сообщений в команде • Ручная отпимизация

9. Реализация

10. Первичный анализ •VMware operations manager •OpenStack

11. Метрики •Owner •TTL •TTL Action •ESX_swap •Snapshot_count •CPU_usage_avg •MEM_usage_avg •Disk_type

12. TTL TTL — дата, по достижению которой с VM производится действие Требуемые значения: ISO 8601 (Basic) или -1 Пример: 20171030 Триггер: выполняем действие из TTL Action Несоответствие требуемым значениям: отправляем письмо owner'у TTL

13. TTL Action TTL Action — действие, которое производится с VM по достижению даты в TTL Требуемые значения: ключевые слова Пример — выключение: shutdown || halt Пример — удаление: remove || delete || destroy Пример — перемещение: archive || mv Триггер: вспомогательный атрибут Несоответствие требуемым значениям: отправляем письмо owner'у

14. Owner Owner — владелец или ответственный за VM Требуемые значения: имя доменной учетки или группа рассылки, допустимо несколько значений Пример — dmiroshnichenko || isimqa; knikolaev Триггер: вспомогательный атрибут Несоответствие требуемым значениям: контактируем с лидами и находим исполнителя который заполнит значения 

15. ESX_swap ESX_swap — объем памяти, которую Vmkernel перевел на диск Требуемое значение: 0 MB Триггер: превышение требуемого значения Несоответствие требуемому значению: отправляем письмо owner'у. Перезагружаем/выключаем ВМ

16. Snapshot_count Snapshot_count — число снапшотов у VM Требуемое значение: 0 Триггер: превышение требуемого значения Несоответствие требуемому значению: отправляем письмо owner'у с просьбой удалить снапшоты

17. CPU_usage_avg & MEM_usage_avg *_usage_avg — cреднее значение по загрузке за 4 часа Рекомендованные значения: загрузка более 60% Триггер: превышение рекомендованного значения Несоответствие рекомендованным значениям: оповещаем owner'а о чрезмерном потреблении ресурсов

18. Disk_type Disk_type — тип диска Требуемые значения: Thick Provision Lazy/Eager Zeroed Триггер: превышение допустимого значения Несоответствие требуемым значениям: отправляем письмо owner'у с просьбой конвертировать диск и количеством «неправильных» дисков

19. Данные: создаем и наполняем

20. Zabbix •Items •Triggers •Logic

21. Items & Triggers

22. Оповещения

23. Выводы

24. Положительные результаты • DoD достигнут: критерии неоптимальности определены, методика и скрипты разработаны • Переходим на парадигму Infrastructure as Code • Единые сборочные пулы • Навели порядок и сэкономили  • Приблизились к созданию единого ресурсного пула

25. Единый вычислительный пул HW HW HW Clouds

26. Что не получилось •Disk_type •CPU_usage_avg •MEM_usage_avg

27. CPU_usage_avg & MEM_usage_avg Как представляли:

28. Что дальше

29. Планы • Построение цикла жизни VM • Дополнительные проверки перед созданием VM • Агрегация VM по Load class • UI • Оповещения об «осиротевших» VM

30. github.com/devopshq

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Владислав Александров

CI-инженер at Positive Technologies

Типовая сборка и деплой продуктов в Positive Technologies

1. Типовая сборка и деплой продуктов в Positive Technologies Александров Владислав CI-инженер valexandrov@ptsecurity.com

2. План • Проблемы в построении CI-процессов в компании • Структура типовой сборки • Пример реализации типовой сборки • Плюсы и минусы от использования типовой сборки

3. Инструменты и сервисы

4. Сервисы DevOps в Positive Technologies

5. Сервисы DevOps для организации CI Сообщество DevOpsHQ: github.com/devopshq

6. Continuous Integration всем и сразу

7. Проблемы • Нет типового шаблона для создания сборочных, деплойных и тестовых конфигураций • Медленное создание типовых проектов в Continuous Integration системах • Отсутствие механизмов масштабируемости проектов

8. Решения • Создать структуру будущих сборок, позволяющую быстро расширять и изменять их • Создать базовые шаблоны и метараннеры в TeamCity • Создать автоматический генератор для TeamCity сборок в DevOps tools

9. Типовой проект в TeamCity

10. Что такое TeamCity и с чем его едят

11. Релизная схема сборок с продвижениями в TeamCity

12. Обобщенная трехуровневая иерархия проектов в TeamCity

13. Типовой интерфейс проектов в TeamCity

14. Метараннеры в TeamCity

15. Структура сборочного процесса в TeamCity

16. Автоматическая генерация конфигураций

17. Root meta-runners

18. Основные root meta-runners • Deploy DevOps-tools — доставляет на сборочные агенты DevOps скрипты • Build prepare — подготавливает окружение перед запуском сборочных метараннеров • Linux build — запускает сборку с определенным компилятором под nix системы • Windows build — запускает сборку с определенным компилятором под win системы

19. Build prepare: основные шаги • Определение версии (major, minor, patch) • Подготовка переменных для сборочных метараннеров • Обновление информации о сборке в UI TeamCity • Обновление build-счетчика • Создание файлов с чувствительной информацией • Перемещение исходников в рабочую директорию

20. Windows/Linux build: основные шаги • Подготовка переменных окружения • Запуск сборочного скрипта (build-on-server) • Создание архива для выкладки • Выкладка финального архива и/или дополнительных компонентов

21. Скрипты автоматической сборки

22. Скрипт сборки (build-on-server)

23. TeamCity агенты Windows • Администрирование командой DevOps • Изменение окружения только командой DevOps • Выделенные пулы для команд Linux • Администрирование командой DevOps • Запуск сборок в Docker контейнерах • Docker контейнеры поддерживаются разработчиками • Единый Linux пул

24. Что получилось

25. Плюсы • Типизированный процесс сборок • Узловые метараннеры и шаблоны • Структура всех компонент в коде • Новый проект? Легко!

26. Минусы • Ограниченная гибкость изменений конфигураций • Сборочные шаги контролируются только DevOps • Изменения окружения практически не обратимы • Одна сборочная конфигурация для всех веток подпроекта

27. Что дальше

28. Дальше — больше • Передать управление шагами сборки в команды • Версионирование Docker образов • Создать единый Windows пул • Автоматизация и еще раз автоматизация

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Алексей Буров

Positive Technologies at DevOps Team

Как мы собираем проекты в выделенном окружении в Windows Docker

1. Как мы собираем проекты в выделенном окружении в Windows Docker Алексей Буров CI-инженер aburov@ptsecurity.com

2. Содержание 1. Как было раньше 2. Проблемы 3. Решение 4. С чем столкнулись

3. Про текущие процессы

4. Что мы имеем

5. Как было раньше

6. Проблема Как поддерживать зоопарк окружения

7. Проблемы 1. Сборочное окружение ломается 2. Командам нужно изменять окружение самостоятельно 3. Иногда не соблюдается требование отказоустойчивости 4. Не сохраняется сборочное окружение прошлых релизов 5. Неполная утилизация ресурсов виртуальных машин

8. Решение Windows Docker

9. Долгожданный • Docker показал себя эффективным инструментом для решения озвученных проблем • Опыт работы в системе сборки с Docker Linux более 4 лет • Своя инфраструктура Docker Registry (Artifactory) • Windows Docker анонсирован в сентябре 2016 года

10. Сложность установки ПО: но это же Windows • Linux • Windows (Пример отсюда)

11. Сложность установки ПО: облегчаем жизнь Упрощаем

12. Сложность установки ПО: облегчаем жизнь

13. Размер ПО: делаем как в Linux Linux • У каждой команды свой docker образ (и не один) • У каждой компоненты может быть свой docker образ • Допускается создание фича-веток docker образов • На сборочных серверах вычищаются все docker образы по ночам

14. Размер ПО: делаем как в Linux Критерий Linux Windows Размер образа с основным набором ПО для компиляции до 5 GB до 45 GB Среднее время сборки образа с нуля до 20 минут до 70 минут Среднее время pull до 3 минуты до 50 минут

15. Размер ПО: делаем по своему Windows • Есть базовые образы, с предустановленным часто используемым ПО o Python o Visual Studio Build Tools o SDKs • У каждой команды есть свой образ, где они могут добавлять ПО • Тестирование новых образов происходит строго на одном сервере • Docker образы очищаются редко, практически вручную

16. Размер ПО: делаем по своему vc140 Visual Studio 2015 SDKs Other vc150 Visual Studio 2017 SDKs Other team1 FROM: vc140 PostgreSQL Python 3.6 x64 team2 FROM: vc150 .NET Core 2.0 Python 2.7 x86

17. Процесс внесения изменений: установка ПО • Сохранить exemsi на сервер по адресу yourstorage.example.ru/win/packages — храним установщики, чтобы меньше зависить от интернета (не всегда получается, как, например, с msbuild-tools) • С помощью USSF (Universal Silent Switch Finder) найти ключи для установки в silent mode • Добавляем строчку с помощью скрипта install-web.ps1 (или download-and- unpack) по аналогии с существующими Примеры Dockerfile доступны по ссылке: github.com/allburov/docker-windows

18. Прочие особенности Windows Docker

19. GetFinalPathNameByHandle • GetFinalPathNameByHandle отображает относительные и прочие пути в полный путь используя ? синтаксис • Неправильно отображает подключенные пути

20. 260 символов хватит всем • Win32 API MAX_PATH=260 — имя файла не больше 260 символов • В Windows Docker проблема появляется. Если к запускаемому докеру подключать директорию, то она подключается как symlink • c:build = • ?ContainerMappedDirectories30FA5B39-9158-4785-A3A9-0435BFF32D2B • Даже если в хостовой системе путь допустимый и меньше 260 символов, то в docker он превращается в более длинный путь • Обещали в локальных политиках дать возможность отключить ограничение на количество символов в имени

21. У каждого слоя свой hostname Проблема установки служб 1. Устанавливается в слое rabbitmq 2. В следующем — запускается 3. Проходят еще шаги 4. Запускается контейнер — но у него уже другой hostname 5. Rabbitmq отказывается запускаться Hostname mismatch: node "rabbit@202fd51f02fd" believes its host is different. Please ensure that hostnames resolve the same way locally and on "rabbit@202fd51f02fd"

22. Silent install & GUI Не всё ПО поддерживает Silent install mode • gvim (vim для Windows) — ранее не поддерживал silent-установку, пришлось править инсталлятор Не всё ПО (даже установщик) может работать без интерфейса • NET SDK 4.0 — устанавливается только в GUI-режиме

23. Что дальше

24. Дальнейшее развитие 1. Версионирование docker образов • Нужно для сохранения при релизах наших продуктов 2. Устанавливать продукты в docker и запускать интеграционные тесты 3. Поставлять dev-окружение контейнерами 4. Поставлять production docker образы Текст доклада и примеры Dockerfile: github.com/allburov/docker-windows

25. Итоги 1. Как было раньше • только группа Continuous Integration имеет доступ к серверам 2. Проблемы • долго • ломалось и нет версионирования • неэкономно 3. Решение • упрощение установки — скрипты, фиксированный процесс • своя схема для Windows 4. С чем столкнулись • Symbolic Links • Silent install mode

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Тимур Гильмуллин

DevOps Team Lead at Positive Technologies

Развитие сообщества Open DevOps Community

1. Развитие сообщества Open DevOps Community Тимур Гильмуллин, Руководитель группы поддержки процессов разработки (DevOps) tgilmullin@ptsecurity.com https://www.linkedin.com/in/tgilmullin 

Александр Паздников, Руководитель отдела технологий и процессов разработки apazdnikov@ptsecurity.com 

2. Проблема на начало 2016: нет готового объединяющего решения для CI/CD-систем

3. Проблемы 2016 года • Отсутствовал готовый каркас открытой системы управления полным циклом процесса разработки, доставки, развёртывания и лицензирования • Отдельные системы: GitLab, TFS, TeamСity, JFrog Artifactory, статьи best practice и блоги, разрозненная документация • Разрозненные знания отдельных специалистов компании о продуктах и их сборке

4. Попытки решения проблем Op!DevOps! 2016: •статья на Хабрахабр •видео Open DevOps Community •на базе GitHub-проекта DevOpsHQ

5. Что мы хотели объединить в DevOpsHQ DevOpsHQ Artifactory TeamCity Upsource GitLab TFS YouTrack TestRail DockerSaltStackZabbix CrossBuilder CrossPM DevOpsLab SupplyLab SymbolServer

6. Цели и проекты в DevOpsHQ

7. Цель сообщества Open DevOps Community Сформировать открытые готовые решения для управления: • полным циклом процесса разработки • тестирования и смежных процессов • доставки • развёртывания • лицензирования продуктов

8. Опубликованные проекты • crosspm — универсальный менеджер для скачивания пакетов для сборок многокомпонентных продуктов, по правилам, заданным в манифесте • vspheretools — инструмент для управления виртуальными машинами на vSphere прямо из консоли, с возможностью подключения в качестве API- библиотеки в Python-скриптах • YouTrack Python 3 Client Library — Python-клиент для работы с API YouTrack • TFS API Python client — Python-клиент для работы с API MS TFS • A Python client for Artifactory — Python-клиент для работы с API хранилища бинарных данных Artifactory • FuzzyClassificator — универсальный нейронечёткий классификатор произвольных объектов, свойства которых могут быть оценены на нечёткой измерительной шкале

9. Готовятся к публикации • CrossBuilder — система организации кросс-платформенных сборок Build As a Code, наподобие Travis CI, но не зависящая от используемой CI-системы (TeamCity, Jenkins, GitLab-CI) • ChangelogBuilder — генератор release notes с описанием изменений по продукту, который получает и агрегирует данные из различных трекеров (TFS, YouTrack, GitLab) • pyteamcity — доработанный python-клиент для работы с API TeamCity • MSISDK — SDK для создания msi-пакетов для инсталляторов

10. Типовой проект • Типовой проект ExampleProject (все проекты под MIT-лицензией)

11. Планы развития DevOpsHQ

12. Ретроспектива • 2015 — настройка базовых сценариев и процессов, построение скелета-каркаса системы DevOps • 2016 — активное наращивание объёмов сборок и тестовых процессов • 2017 — закрепление успехов и стабилизация роста, качественный переход на удобство использования • впервые: годовой план для крупных задач • цель: получение общего Конечного Полезного Результата

13. Цели и функции DevOps в PT • Основная цель DevOps — обеспечение снижения себестоимости производства Конечного Полезного Результата • Основная функция DevOps — макросборка частей в единый полезный конечный продукт и сокращение себестоимости цепочки: производство — доставка — развёртывание ПО

14. SupplyLab: система доставки обновлений Система SupplyLab в 2017 году в цифрах: 1.Заказчики выкачали 80 Тб обновлений 2.Было опубликовано порядка 20 релизов продуктов 3.Было опубликовано ~2000 пакетов обновлений с данными Планы по SupplyLab на 2018: 1.Разделить кодовую базу ядра и лицензионных проверок 2.Публикация в DevOpsHQ

15. Вектор целей управления на 2018 1.Обеспечение стабильности процессов разработки 2.Регулярное проведение вебинаров о существующих наработках, для обеспечения серийности производства 3.Анализ процессов продуктовых команд для выявления узких мест, которые может решить DevOps 4.Перевод на серийное дублирование процессов в командах

16. Направления развития в 2018 1.Расширение серийности — добавление новых типовых сборочных шаблонов, в первую очередь, за счёт CrossBuilder 2.Ввод в эксплуатацию системы управления составом релиза и качеством входящих пакетов (CrossPM + DevOpsLab) 3.Типовой процесс поставки через систему обновления SupplyLab 4.Выход на технологию Infrastructure as Code 5.Профилирование и оптимизация процессов сборки, развёртывания, доставки

17. Планы DevOpsHQ на 2018 1.Разработка CrossBuilder — открытой системы Build As a Code и шаблонов типовых проектов для неё 2.Управление составом дистрибутива на базе сборочных контрактов пакетов и их меток качества 3.Разработка DevOpsLab — системы автоматизации и делегирования типовых задач в проектные команды

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Tickets

Video
Access to all videos
Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Organizer

Positive Technologies
https://www.ptsecurity.com

Organizer committee: Positive Technologies, pt@ptsecurity.co, 74957440144

Similar events

November 16 2017
Talks 23
Views 1.44 K
devops, автоматизация, бизнес-процесс, по, прогарммирование, разработка, софт, управление
November 12 2017
Talks 7
Views 1.13 K
бизнес-процесс, менеджемент, по, разработка, софт, управление
April 21-22 2017
Talks 66
Views 14.71 K
development, devops, hr, менеджемент, прораммирование, разработка, софт, управление
more