Последние публикации

С точки зрения СУБД, соединение с клиентским приложением – ресурс, которым надо тщательно управлять для аккуратного расходования системных ресурсов. Практически все СУБД устанавливают таймауты неактивности соединения, после достижения которых данное соединени разрывается в одностороннем порядке. Обычно, приложения узнают о данном факте уже после того, как соединение разорвано. В случае с MySQL, клиент получает сообщение The MySQL server has gone away (error 2006). В статье мы рассмотрим подходы, которые позволяют приложениям c долгоживущими соединениям, поддерживать их столько, сколько требуется. Примеры будут приводиться для стандартного интерфейса подключения к СУБД MySQL – mysql.connector. Язык примеров – Python3, в качестве прикладного примера будет использоваться микросервис, реализованный на фреймворке Tornado.

В предыдущей статье мы начали говорить о моделях ветвления при работе с Git и рассмотрели модель Feature Branch Workflow. В данной статье мы рассмотрим еще одну популярную модель ветвления – Gitflow.

Данная статья является переводом англоязычной статьи из обучающих материалов Atlassian.

Модель ветвления Gitflow была впервые опубликована и стала популярной, благодаря статье Vincent Driessen. Она предполагает выстраивание строгой модели ветвления вокруг релиза проекта, которая дает надежную схему управления крупными проектами.

Gitflow отлично подходит для проектов, которые имеют спланированный цикл релиза. Эта модель не предполагает дополнительных понятий, кроме тех, что описаны для модели Feature Branch Workflow. Вместо этого она приписывает особые роли разным веткам и определяет, как и когда они должны взаимодействовать. Кроме feature-веток в ней используются отдельные ветки для подготовки, поддержки и записи релиза. Конечно, также необходимо эффективно использовать все преимущества Feature Branch Workflow: пул-реквесты, изоляция для изменений и эффективное сотрудничество внутри команды.

Gitflow использует собственный набор инструментов git-flow, который легко интегрируется с Git, добавляя новые команды Git.

При работе с Git важно выбрать подходящую модель ветвления, максимально отвечающую потребностям команды. Существует множество различных моделей. Например, Atlassian рассматривает 4 вида моделей. В этой статье мы рассмотрим модель Feature Branch Workflow.

Данная статья является переводом англоязычной статьи из обучающих материалов Atlassian.

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

Изоляция работы над новой функциональностью также позволяет эффективно использовать запросы на объединение кода (pull request, merge request), которые являются способом инициализации обсуждения изменений, созданных в ветке. Они дают другим разработчикам возможность одобрить функциональность перед интегрирацией в официальный проект. Или, если в процессе работы над функциональностью разработчик столкнулся с проблемой, он может создать запрос на объединение и спросить совета у коллег. Суть в том, что запросы на объединение позволяют участникам команды комментировать работу друг друга.

Модель Feature Branch Workflow можно эффективно использовать как базу для других высокоуровневых схем работы с Git. В модели Feature Branch Workflow в центре внимания – ветвление, это значит, что она является основной используемой моделью для создания веток и управления ими. Так, она обычно используется в моделях Gitflow и Forking Workflow для организации ветвления.

По мере проникновения контейнеров в продуктовые среды у системных администраторов и разработчиков возникает необходимость мониторинга текущих рабочих показателей контейнеров и сбора метрик для анализа. В этой статье вы сможете узнать, какие механизмы для решения этой задачи могут быть использованы при использовании Docker.

Данная статья является переводом англоязычной статьи из официальной документации Docker. В процессе перевода мы постарались упростить статью.

Данная статья является переводом англоязычной статьи Владислава Супалова.

В связи с последними релизами в мире Docker произошли некоторые изменения. В версии 1.12 в Docker Engine был интегрирован режим Swarm, в связи с чем появилось несколько новых инструментов. Среди прочего, теперь появилась возможность использовать Compose-файлы docker-compose.yml для создания стеков контейнеров Docker без необходимости устанавливать инструмент Docker Compose.

Теперь для этого есть команда docker stack, и она очень похожа на docker-compose. Сравните:

$ docker-compose -f docker-compose up

$ docker stack deploy -c docker-compose.yml somestackname

Обе команды создают все сервисы, тома, сети и все остальное, что определено в файлах docker-compose.yml. Почему получилось так, что возникли два очень похожих инструмента, которые выполняют одну задачу? Отличается ли docker stack от docker-compose? Зачем создали docker stack? Что следует учитывать, кроме синтаксиса?