Workflow или организация рабочего процесса в веб-студии

Workflow или организация рабочего процесса в веб-студии

Когда над проектом работает команда, то непременно возникают вопросы:

  • как разделить работу, чтобы не мешать друг другу и соответственно избежать конфликтов
  • тестирование и исправление ошибок
  • разделение на версии и демонстрация проекта клиенту на разных стадиях

 

В статье представлены две версии рабочего процесса, первая версия родилась из-за нехватки финансовых ресурсов и может подойти тем, кто хочет при минимальных затратах организовать воркфлоу в команде. Вторя версия наиболее распространенная и о ней будет не так много текста.

 

Перед тем как начнём

В основе всех правил и рабочих схем является работа с системой управления версиями – Git

С которой обязаны уметь работать все. Мы используем BitBucket в качестве основного провайдера услуг по хранению и управлению Git репозиториями. Выбор был сделан не случайно, внутри команды/компании мы используем JIRA для управления проектами и задачами и эта система выпущена и поддерживается той же как компанией, что и BitBucket по этому JIRA + BitBucket = 100% совместимость.

 

Схема 1

Была разработана с учетом того, что бы не запускать проекты локально (на рабочем) компьютере, а где-то на сервере. Этим сервером является наиболее мощный компьютер в локальной сети.

 

Сервер

Все проекты работают под своими пользователями например: project1, project2 под которыми мы разработчики будем заходить на сервер используя SFTP/SSH

В качестве бекграунда используется Apache + php-fpm (нужен чтобы запускать процессы под определенными пользователями)

 

Структура папок на сервере

Project1/

— public_html (папка основного стейджа) https://staging.company.com/

— logs (логи стейджа и команды)

— team (основная папка где хранятся директории команды)

—- m1 (папка первого разработчика) https://m1.staging.company.com/

—- m2 (папка второго разработчика) https://m2.staging.company.com/

 

Папка медиа расшаривается (symlink) на всех разработчиков, а так же другие ресурсы, которые являются общими.

Базы данных две, одна у основного стейджа, другая у разработчиков.

 

Примечание

Мы специализируемся на Magento проектах и вопрос разделения БД, медиа данных у нас стоит иначе. Тут есть свои плюсы и минусы. Плюсом будет то, что все данные: товары, категории, атрибуты, заказы и т.п. становятся доступны сразу всем разработчикам.

Минусом будет то, что если будет добавлен атрибут с зависимостью от класса (файла) который есть только у одного разработчика, то работа на какое то время парализуется.

Ниже пример local.xml файла, через настройку которого мы решаем вопрос с разными УРЛами на одной БД

 

<config>
    <stores>
        <default>
            <web>
                <unsecure>
                    <base_url>http://m1.staging.company.com/</base_url>
                </unsecure>
            </web>
        </default>
        <admin>
            <web>
                <unsecure>
                    <base_url>http://m1.staging.company.com/</base_url>
                </unsecure>
            </web>
        </admin>
    </stores>
</config>

Этот файл позволяет переопределять любые настройки админ панели в том числе и основной УРЛ сайта

 

Преимущества

Значительная экономия локальных ресурсов – HDD так как работаем локально только с кодом, медиа и БД находятся на сервере.

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

Работать на практически любом ПК из любого места где есть интернет. Для нас это было очень важно, так как у нас не было мощных компьютеров.

Нет необходимости настраивать локальный сервер на рабочей станции, для чего могут потребоваться определенные знания и время.

Можно работать в локальной сети без интернета.

 

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

 

Недостатки

Сервер должен быть всегда онлайн, если работать вне офиса и у вас нет интернета, соответственно работать не получится.

Затрудняется процесс отладки, что может быть очень важным, ведь тот же xDebug лучше запускать на рабочей станции. Если запускать удаленно, то будет весьма ощутимая нагрузка на сервер и другие проекты которые на наем работают будут работать медленно, что может парализовать работу всей команды.

 

Рабочая станция

Тут достаточно обычная схема. Клонируется репозиторий на базе которого создается проект. В настройках проекта указываем: удаленный сервер и папку (у каждого разработчика своя) куда будут выгружаться файлы.

При первой инициализации проекта потребуется выгрузить все файлы или используя консоль SSH скопировать файлы с основного стейжа в папку разработчика или можно это сделать сразу для всех.

 

Тестирование

Учитывая то, что над проектом может работать много разработчиков и каждый из них выполняет определенную задачу или даже группу задач, то ход выполнения над процессом можно наблюдать на каждом хосте разработчика. Например верстка страниц А, Б, С на хосте м1, а блог можно посмотреть на хосте м2 это может быть очень удобно для клиента, ведь можно показывать процесс по нескольким направлениям.

После коммита и слияния ветки в мастер (это может быть какая то отдельная ветка для разработки), включается в работу TeamCity continuous integration server который может запускать тесты, различные команды, утилиты по созданию документации, отправлять уведомления и если все операции (запуски команд) прошли успешно то проект отправляется на основной стейдж , так же может быть обновлен и клиентский стейдж. Действия разработчика сводятся к минимуму по дополнительным операциям над кодом.

Схема №2

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

 

Преимущества

Работать можно без интернета. Отлаживать проект локально проще, не нужно дополнительных настроек, как для сервера, чтобы например подключится к xDebug удаленно и это не мешает другим разработчикам.

 

Недостатки

Не все проекты запускаются сразу и требуются определенные знания, особенно если вы работаете  на Windows и бывает на разворачивание проекта уходят часы.

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

В репозитории требуется хранить не только основной код но и дополнительные файлы, которые могут потребоваться для запуска проекта.

 

На текущий момент мы активно используем обе схемы работы и скорее всего это уже дело выбора или привычки. Когда ты знаешь Magento очень хорошо и не требуется тратить уже столько времени на изучение кода, то подходит вариант №1

Из дополнительных инструментов в работе активно используются Scrutinizer  в основном для проверки на ошибки, Blackfire – профилировщик кода.