Несколько слов об эволюции Centralized Version Control System

DevOps_Deep_27.11_site-5020-2d2668.png

СVCS (Centralized Version Control System) — централизованные системы контроля версий, работа которых основана на том, что на сервере имеется одна центральная копия проекта, а программисты совершают свои изменения в этой центральной копии.

Как мы работаем с GitHub на курсе DevOps?

DevOps_Deep_26.10_site-5020-0ec557.png

На курсе «DevOps практики и инструменты» мы обучаем работе с Git’ом, как с инструментом командной работы. А также говорим про важность описания инфраструктуры, метрик мониторинга, скриптов сборки и всего-всего в виде кода. И в программе курса из практики нет ничего, что не ложилось бы в код.

А раз можно описать в коде, то можно хранить в Git’e. Github значительно популярнее облачного Bitbucket’а и Gitlab’а. Мы с ним умеем работать и поэтому выбрали именно его.

Расширения и настройки VS Code для DevOps-специалистов

DevOps_Deep_11.3_site-5020-223cd0.png

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

О новом подходе к интеграции TravisCI с GitHub

DevOps_Deep_6.11_site-5020-4ad3ad.png

В мае 2018 года разработчики TravisCI анонсировали объединение коммерческой и Open Source версий. Теперь, чтобы добавить TravisCI в свой проект на гитхабе, нужно использовать не Services, как раньше, а GitHub Marketplace.

Trunk-based Development

DevOps_Deep_11-5020-1f219d.09_site.png

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

Ansible: формируем переменные на всех хостах с Custom facts

DevOps_Deep_21.08_site.png

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

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

Модуль setup и Gathers facts в Ansible

DevOps_Deep_17.08_Site.png

В системе управления конфигурациями Ansible есть специальный модуль setup. Он выполняется первым, собирая информацию (Gathers facts) обо всех подключённых узлах (нодах). При выполнении модуля на хосте он собирает разные факты, включая дисковое пространство, версию и тип операционной системы, hostname машины, количество доступной памяти, архитектуру процессора, IP-адреса, сетевые интерфейсы и их состояние.

Trytravis: тестируем без коммитов и пушей в удалённый репозиторий

DevOps_Deep_LAST_11.07_1_site.png

TravisCI – популярный распределённый веб-сервис для сборки и тестирования кода. Многие используют его, т.к. для OpenSource-проектов он доступен бесплатно и обеспечивает удобную интеграцию с GitHub.

При этом отлаживать билды в Travis не всегда удобно. Для упрощения данной задачи Seth M. Larson разработал прекрасную утилиту trytravis. Она позволяет тестировать изменения в репозитории без коммитов и пушей в удалённый репозиторий.