Сразу оговорка. Название tochka workflow является собирательным, поскольку именно в компании Точка впервые пришлось столкнуться с данной моделью ветвления.
Данная модель ветвления довольно популярна в больших компаниях, где каждый проект тесно связан с другими активно развивающимися проектами внутри этой самой компании. Tochka workflow очень похож на gitflow, но вместе с тем, эта модель ветвления решает известную проблему gitflow: если при подготовке релиза необходимо срочно отказаться от некоторой функциональности проекта, gitflow для этого просто не предусмотрен, такая ситуация может добавить головной боли команде. В tochka workflow такой проблемы нет. В связи с тем, что в статье часто будут проводиться параллели с gitflow, перед дальнейшем прочтением статьи, целесообразно ознакомиться с gitflow тем, кто не знаком с этой моделью ветвления. Описание gitflow доступно здесь.
В обеих моделях есть две основные ветки – master и develop. Точно также изначально от master-ветки fork’ается ветка develop.
tochka workflow. Develop-ветка
Но если назначение ветки master одинаково – там хранятся все релизы проекта, то есть находится код, который всегда готов быть отправлен на рабочку. С develop-веткой все несколько иначе. В gitflow в develop-ветке ведется разработка, в tochka workflow ветка develop необходима для тестирования функциональности.
Читать далее
Бывают ситуации, когда необходимо рассчитать дату с учетом именно рабочих, а не календарных дней. На какую-либо алгоритмизацию здесь полагаться достоверно не приходится, поскольку правительство РФ то и дело штампует исключения из правил. То новогодние выходные перенесут на май, то субботу сделают рабочей, а выходной перенесут на будний день. И так каждый год! И все эти ситуации необходимо учитывать.
В интернете на этот счет есть несколько решений, но все они либо некорректные, либо совершенно неудобные. Несколько таких решений: Один, Два и Три.
В связи с таким положением дел и был написан класс WorkCalendar, позволяющий удобно работать с производственным календарем. WorkCalendar расширяет возможности класса Carbon\Carbon, поэтому работать с ним одно удовольствие. Итак, добавленные методы:
-
isWorkday(): bool - true, если день рабочий, иначе false. Один из наиболее удобных методов. Позволяет выяснить, является ли текущий день рабочим. Пример:
$workday = WorkCalendar::create('2018', '02', '22');
print_r($workday->isWorkday()); // true
$workday = WorkCalendar::create('2018', '02', '23');
print_r($date->isWorkday()); // true
-
diffInWorkdays(WorkCalendar $carbon): int - возвращает разницу в рабочих днях между двумя датами. Может возвращать отрицательное значение, если передаваемая дата меньше(раньше) текущей. Пример:
$first = WorkCalendar::create('2018', '02', '23');
$second = WorkCalendar::create('2018', '02', '08');
print_r($first->diffInWorkdays($second)); // 8
-
addWorkday() - добавить рабочий день к текущей дате. Пример:
$first = WorkCalendar::create('2018', '02', '26');
$first->subWorkday();
print_r($first->format('Y-m-d')); // 2018-02-22
-
subWorkday() - отнять рабочий день от текущей даты. Пример:
$first = WorkCalendar::create('2018', '02', '26');
$first->subWorkday();
print_r($first->format('Y-m-d')); // 2018-02-22
-
addWorkdays(int $count) - добавить $count рабочих дней к текущей дате. Крайне полезен в ситуациях "через 10 рабочих дней", "в течение 5 рабочих дней", коими грешат наши государственные конторы. Пример:
$first = WorkCalendar::create('2018', '03', '01');
$first->addWorkdays(5);
print_r($first->format('Y-m-d')); // 2018-03-12
-
subWorkdays(int $count) - отнять $count рабочих дней от текущей даты. Пример:
$first = WorkCalendar::create('2018', '03', '12');
$first->subWorkdays(5);
print_r($first->format('Y-m-d')); // 2018-03-01
Читать далее
Пожалуй, наиболее популярная модель ветвления git, вместе с тем и довольно сложная. Вся идея этой модели сконцентрирована вокруг одной мысли: над проектом должно быть удобно работать команде разработчиков. Данная модель идеально подойдет для проектов, которые придерживаются определенного релизного цикла.
Как это работает
В самом начале в master-ветке делается какой-то начальный коммит. Master-ветка содержит код, который всегда готов быть отправлен на рабочку. Обычно каждому обновлению кода ветки master присваивают релизный номер в теге. Таким образом, master-ветка содержит все релизы проекта. Так, первому коммиту можно присвоить тег v0.0.1 и считать, что это отправная точка проекта. После этого от master fork’ается ветка с говорящим названием develop. В develop-ветке находятся последние наработки по проекту, которые напрямую не коммитятся в develop. Все изменения кода выполняются в так называемых feature-ветках - для каждой фичи своя отдельная ветка.
Читать далее
Решил ввести практику подведения итогов для блога по прошедшему году. Главным образом, раскрыть информацию, провести кое-какую аналитику, а также наметить векторы развития. Еще решил сформировать что-то типа приблизительного дайджеста новых статей на текущий год, чтобы читатель понимал, стоит ли следить за обновлениями или нет, а также хочу указать целевые показатели для блога, к которым буду стремиться (ну и для обзора на следующий год не помешает). Буду рад к диалогу с читателями насчет моей аналитики показателей блога.
Обзор за 2017 год
За 2017й год было опубликовано целых 9 статей. Последняя статья датируется аж июлем месяцем. Крайне низкое количество статей, а также совершенно отсутствует регулярность.
Читать далее
В современном мире разработки знание команд для работы с git не означает обязательный успех в командной разработке. В команде важно закрепить какой-либо способ работы с git: какая ветка является основной для разработки, когда необходимо производить слияние веток, какая из них является той, которая выгружается на рабочку, и т.д. Набор таких правил называется моделью ветвления (англ.: workflow). В зависимости от того, над каким проектом вы работаете, а также какую модель ветвления в git вы используете и определяется эффективность работы команды разработчиков.
Использование модели ветвления git – эта командная практика работы с репозиторием. Следование данной практике, удается добиться организованности в работе, минимального количества конфликтов в коде, а также определить подходящий для команды способ публикации изменений в проекте.
Существует несколько наиболее известных моделей ветвления git, которые подходят практически для любого случая. Если вы впервые слышите про модели ветвления, или хотели бы расширить свой кругозор – то этот цикл статей именно для вас. Однако, следует помнить, что любая модель ветвления - это не набор жестких правил. Всегда можно адаптировать модель под себя.
Несмотря на большое количество моделей ветвления, все они используют одну очень полезную практику: для написания той или иной функциональности нельзя использовать основную ветку, необходимо все изменения вносить в промежуточной ветке, которая потом вливается в основную через механизм pull-request. Дело в том, что такой механизм позволяет организовать просмотр внесенных изменений коллегами, выполнение автоматических тестов, прогон кода через статические анализаторы. И только при выполнении обязательных шагов можно будет влить изменения из промежуточной ветки в основную. Именно эти дополнительные шаги и позволяют увеличить качество кода проекта.
В данном цикле статей предполагается, что у читателя имеется базовый опыт работы с git, он ориентируется в терминах git: коммит, слияние, ветка, репозиторий, pull-request, fork. Также предполагается, что читатель умеет работать с git. Статьи преследуют цель показать суть той или иной модели ветвления, а не подробнейшее описание моделей.
Описание популярных моделей ветвления начнется с одной из самых простых – github flow.
Читать далее
В последнее время все более активно продвигается идея построения событийно-ориентированной архитектуры программного обеспечения. Такая архитектура предполагает, что её компоненты - отдельные сервисы, общаются между собой путем отправки асинхронных событий через общую шину ESB. Событие – это сообщение (например в терминологии AMQP), у которого есть название и набор параметров. Обычно событием является запрос какой-то информации, либо это может быть просто уведомление о чем-то заинтересованных сторон. В общем случае, событие отправляется безадресно, то есть без конкретных знаний, какой сервис должен получить данное событие. Конкретные же сервисы слушаю общую шину на предмет появления в них тех или иных событий или запросов с целью реагирования. Прелесть построения событийно-ориентированной архитектуры в том, что сервис-отправить может отправить событие в шину и, не дожидаясь ответа, приступить к выполнению других важных задач. Ответ будет получен позже также через шину.
Схема использования ESB
Шина обычно представляет собой набор очередей, внутри которых и находятся сообщения. В очередь можно как записать сообщение, так и получить его, удалив из очереди. Программное обеспечение, реализующее и управляющее очередями, предоставляющее API для работы с ними, называется брокером сообщений. Наиболее известные брокеры сообщений это ZeroMQ, ActiveMQ, RabbitMQ.
Читать далее
Со временем любой PHP-программист сталкивается с проблемой низкой производительности своего приложения. Это может быть медленная загрузка конкретной страницы или слишком долгий ответ от API. И порой достаточно сложно понять, в чем причина тормозов? Порой случаются более сложные ситуации: на боевом сервере api сильно тормозит, но на стенде, где происходит разработка, - все хорошо. И пойди разберись, что идет не так. Производить отладку на рабочем сервере - это крайняя степень безысходности, до которой, конечно, лучше не доводить.
Именно для таких ситуаций и были придуманы специальные инструменты, называемые профилировщиками приложений. В мире PHP эту роль выполняют xDebug, а также xhprof. xhprof является более легковесным, простым и гибким инструментом, поэтому его использование более предпочтительно. Что интересно, xhprof был разработан в facebook еще в 2009 году, однако до сих пор от них нет официальной поддержки php7 и больше не будет, поскольку facebook перешел на HHVM. Однако, благодаря обширному сообществу php-разработчиков, появился форк, поддерживающий php7, установка которого не вызывает каких-либо сложностей.
Читать далее
Цикломатическая сложность (Cyclomatic Complexity Number, ccn) программного кода является одной из наиболее старых метрик. Впервые эта метрика была упомянута в 1976 году Томасом МакКэбом. Эта метрика подсчитывает доступные пути выполнения кода во фрагменте программного обеспечения, чтобы определить его сложность. Каждый путь выполнения включает одну условную конструкцию из приведенного ниже списка, так что это их довольно легко обнаружить в существующем исходном коде:
?caseelseifforforeachifwhile
В данном случае нет конструкций else и default, потому что они в любом случае предполагают использование конструкций if и case, которые присутствуют в списке.
Читать далее
Статический анализ кода — процедура, выполняемая над исходниками программы с целью выявления метрик программного обеспечения. Соответственно, статический анализатор — это утилита, выполняющая данную процедуру. Метрики программного обеспечения — это просто сумма каких-то последовательностей или фрагментов кода, найденные в анализируемом источнике. Например, цикломатическая сложность — это всего лишь сумма всех логических элементов(if, for, while, case и т. д.) в анализируемом фрагменте. Самой же простой и понятной метрикой программного обеспечения является количество строк кода программы.
Читать далее
Ритм разработки программного обеспечения из года в год все ускоряется. Если раньше было возможным применять водопадную модель разработки ПО, когда программа от стадии задумки до стадии релиза проживала в разработке и тестировании многие годы, прошли. Сейчас это совершенно неприемлемо. Даже более совершенная итеративная модель разработки, которая предполагает достаточно частые релизы 1-4 раза в месяц, и то уже не отвечает потребностям рынка. Современный ритм разработки программ требует, чтобы фичи выкатывались в релиз как можно быстрее после разработки. А ведь фичу необходимо еще и полноценно протестировать. Именно как ответ на данные вызовы появились такие практики как непрерывная интеграция и непрерывная доствка программного кода в арсенале современных команд разработки.
Непрерывная интеграция (англ. Continuous Integration, CI) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Обычно сборка проекта осуществляется после внесения изменения разработчиком в код, либо через определенные промежутки времени, например, каждые 20 минут. В любом случае, за определенной сборкой закрепляется определенный коммит в репозитории кода.
Касательно PHP-кода термин "сборка" подразумевает прохождение текущим кодом какого-то набора важных процедур, позволяющих составить представление о качестве кода. Здесь главную роль играет прохождение всякого рода автоматических тестов. Тесты могут выявить уже известные проблемы в системе. В случае, если после очередного коммита в коде всплывает какая-то ошибка, то разработчики тутже об этом знают - вот, где вся прелесть непрерывной интеграции. Соответственно, чем больше тестов написано на известные проблемы, тем спокойнее писать новый код зная, что если что-то пошло не так - ты обязательно об этом узнаешь и все исправишь.
Читать далее