Comments 9
Расскажите пожалуйста:
— Какие зависимости у вас необходимы чтобы протестировать одно собранное решение? ( один, сервер, группа серверов)
— Если несколько серверов, то как вы их получаете\управляете? Vmware только для получения VM руками?
— Для чего именно у вас используется Docker?
— Какие зависимости у вас необходимы чтобы протестировать одно собранное решение? ( один, сервер, группа серверов)
— Если несколько серверов, то как вы их получаете\управляете? Vmware только для получения VM руками?
— Для чего именно у вас используется Docker?
1. Под каждый проект (комплексный процесс, включающий в себя сборку инсталлятора и компонент для него, деплой их на тестовые сервера и автоматизированное тестирование):
2. Для управления виртуальными машинами (включение, выключение, откаты ВМ на снапшоты, запуск процессов и прочее) мы используем vSphereTools. Про автоматическое управление виртуальными машинами будет рассказано в 6-й статье нашего цикла «vSphereTools — инструмент для автоматизации работы с vSphere». Предварительно презентацию с доклада по этому инструменту можно посмотреть здесь: www.slideshare.net/phdays/vspheretools-vsphere
3. Docker используется в нашей инфраструктуре для различных целей:
- в TeamCity выделяется пул сборочных серверов (обычно 1-4 машины на проект), за поддержку которых отвечает DevOps. На этих машинах запускаются только сборочные конфигурации, шаги которых компилируют исходный код (хранимый в GitLab), получают артефакт (одну версию собранной компоненты или всего инсталлятора) и выкладывают его в Artifactory для хранения.
- в TeamCity выделяется пул деплойных серверов (также 1-4 машины на проект). В этом пуле запускаются только деплойные конфигурации, которые отвечают за доставку артефактов сборки на сервера тестирования. За деплойные конфигурации и пулы отвечать может как команда DevOps, так и QA.
- в TeamCity выделяется пул серверов для тестирования (сколько угодно, в зависимости от требований команды QA), за которые отвечает команда QA. В этом пуле запускаются конфигурации, которые выполняют автоматические функциональные тесты на собранные компоненты или инсталляторы. По результатам тестов артефакты компонент или инсталляторов могут быть «продвинуты» (скопированы) в специальные репозитории на Artifactory для хранения протестированных сборок. Иногда деплойные и тестовые сервера могут быть в одном пуле (для небольших проектов).
2. Для управления виртуальными машинами (включение, выключение, откаты ВМ на снапшоты, запуск процессов и прочее) мы используем vSphereTools. Про автоматическое управление виртуальными машинами будет рассказано в 6-й статье нашего цикла «vSphereTools — инструмент для автоматизации работы с vSphere». Предварительно презентацию с доклада по этому инструменту можно посмотреть здесь: www.slideshare.net/phdays/vspheretools-vsphere
3. Docker используется в нашей инфраструктуре для различных целей:
- для подготовки контейнеров со сборочным, деплойным и тестовым окружением для проектов,
- сервисы, которые мы предоставляем как отдел DevOps (TeamCity, Artifactory, GitLab, Youtrack, UpSource, Zabbix и все остальные) для всех команд.
Интересно было бы узнать сколько у вас людей в DevOps-команде и участвует ли ИТ-отдел в этой деятельности?
Девопс-команда из программистов набиралась, qa, админов или извне?
Спасибо
Девопс-команда из программистов набиралась, qa, админов или извне?
Спасибо
Сейчас наша команда DevOps – это выделенный отдел в компании. Разумеется, мы тесно сотрудничаем с коллегами из ИТ-отдела: они помогают нам решать сетевые и инфраструктурные вопросы, и вопросы связанные с бекапами. Все наши сервисы расположены на машинах, «живущих» в облаке, предоставляемом ИТ-отделом.
Команда у нас смешанная, с крайне размытой специализацией (но она всё же есть), коротко: есть QA + Dev + IT. Есть у нас сотрудники с большим опытом работы с трекинговыми системами, есть сотрудники, которые в основном занимаются разработкой типовых сборочных конфигураций, есть сотрудники поддерживающие сервисы мониторинга, есть разработчики внутренних инструментов и прочие.
Команда у нас смешанная, с крайне размытой специализацией (но она всё же есть), коротко: есть QA + Dev + IT. Есть у нас сотрудники с большим опытом работы с трекинговыми системами, есть сотрудники, которые в основном занимаются разработкой типовых сборочных конфигураций, есть сотрудники поддерживающие сервисы мониторинга, есть разработчики внутренних инструментов и прочие.
Можете чуть подробнее рассказать как используется Artifactory и привести конкретный пример использования в вашей системе? Может ткнете ссылкой (кроме оф сайта) на какие-то статьи?
Добрый день. Artifactory сейчас у нас используется для различных целей. Основная — это хранилище бинарных артефактов от сборок компонент, из которых потом собираются инсталляторы продуктов.
Еще это хранилище релизных инсталляторов продуктов, которые прошли тестирование и готовы к распространению через корпоративные серверы обновлений GUS/FLUS.
Кроме того, мы используем artifactory как кеширующий прокси для внешних ресурсов — есть возможность подключить его для проксирования pypi, npm, rpm, nuget и других видов пакетов для пакетных менеджеров. Таким способом мы страхуем наши сборочные процессы от недоступности внешнего интернета или удаления пакетов из облачных хранилищ.
Автоматизацию внутри CI/CD-конвейера мы реализуем с помощью Python-библиотеки, поддерживаемой нами в опенсорсе: github.com/devopshq/artifactory
Отдельных статей по настройке и использованию artifactory мы пока не писали, так как он лишь один из элементов нашего комплексного CI/CD-конвейера — нет смысла рассматривать его отдельно, например, от CI-системы GitLab CI, хранилища кода GitLab или серверов доставки обновлений GUS/FLUS.
Наш комплексный конвейер и процессы разработки упоминаются в более свежих статьях про Dev(Sec)Ops процессы. Посмотрите, возможно, что-то окажется полезным:
• Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps (2017)
• Моделирование производственных процессов в ИТ-компании (2018)
• Управление хаосом: наводим порядок с помощью технологической карты (2019)
• Личный опыт: как выстроить карьерный рост в отделе DevOps (2020)
• Как работает команда DevOps в Positive Technologies (2021)
• DevSecOps: как мы внедряли PT Application Inspector в наш продуктовый конвейер (2020)
• DevSecOps. PT Application Inspector в разработке ПО: блокировка релиза (2021)
Еще это хранилище релизных инсталляторов продуктов, которые прошли тестирование и готовы к распространению через корпоративные серверы обновлений GUS/FLUS.
Кроме того, мы используем artifactory как кеширующий прокси для внешних ресурсов — есть возможность подключить его для проксирования pypi, npm, rpm, nuget и других видов пакетов для пакетных менеджеров. Таким способом мы страхуем наши сборочные процессы от недоступности внешнего интернета или удаления пакетов из облачных хранилищ.
Автоматизацию внутри CI/CD-конвейера мы реализуем с помощью Python-библиотеки, поддерживаемой нами в опенсорсе: github.com/devopshq/artifactory
Отдельных статей по настройке и использованию artifactory мы пока не писали, так как он лишь один из элементов нашего комплексного CI/CD-конвейера — нет смысла рассматривать его отдельно, например, от CI-системы GitLab CI, хранилища кода GitLab или серверов доставки обновлений GUS/FLUS.
Наш комплексный конвейер и процессы разработки упоминаются в более свежих статьях про Dev(Sec)Ops процессы. Посмотрите, возможно, что-то окажется полезным:
• Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps (2017)
• Моделирование производственных процессов в ИТ-компании (2018)
• Управление хаосом: наводим порядок с помощью технологической карты (2019)
• Личный опыт: как выстроить карьерный рост в отделе DevOps (2020)
• Как работает команда DevOps в Positive Technologies (2021)
• DevSecOps: как мы внедряли PT Application Inspector в наш продуктовый конвейер (2020)
• DevSecOps. PT Application Inspector в разработке ПО: блокировка релиза (2021)
.
Sign up to leave a comment.
Личный опыт: как выглядит наша система Continuous Integration