Open Source. Часть I

Как организовать работу с GitHub

Мотивация

Сегодня в своей повседневной работе я активно использую инструменты с открытым исходным кодом, такие как Docker, Kubernetes, Ansible, созданные и поддерживаемые сообществами, состоящими не только из энтузиастов, но и профессионалов, работающих над этими проектами на коммерческой основе.

От каждого по способностям, каждому по потребностям

Этот социалистический лозунг очень хорошо описывает происходящее в таких сообществах - труд, как первая потребность. Вообще, движение свободного программного обеспечения существует уже давно. Вокруг этого движения возникают различные некоммерческие организации, например Open Source Initiative, фонды, среди которых Free Software Foundation и Apache Software Foundation, а также инфраструктурные проекты типа SourceForge и Google Code, однако, по моему мнению, качественный рост этого движения связан с появлением такого игрока, как GitHub, в основе успеха которого - социальная механика, продуманный UX и простота.

Какова же моя мотивация? Что заставляет меня тратить своё свободное время и публиковать свои наработки в открытый доступ? На этот вопрос сложно дать однозначный ответ - это и желание самореализоваться в профессиональной сфере, и желание быть частью сообщества настоящих фанатов своего дела, и желание быть полезным этому обществу. Определённо, я вдохновляюсь такими людьми как Fabien Potencier и Mitchell Hashimoto. Эти люди являются лидерами мнений, и своё лидерство они заработали упорным трудом и талантом.

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

Приступая к работе

Базовые возможности

Классификация

GitHub labels: позволяют визуально разделять и приоритезировать задачи.

GitHub labels

Эпики

GitHub milestones: объединяют задачи в “наборы”, со своим описанием и планируемым сроком завершения работы.

Hub milestones

Канбан-доски

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

GitHub projects

База знаний

GitHub wiki: предоставляет возможность написания документации, спецификаций, глоссария со своей историей изменений.

GitHub wiki

Работа над задачами

Как правило, отправной точкой для меня служит приложение Заметки, которое всегда под рукой.

Notes

Туда я записываю наброски будущих задач и всё, что с ними связано: требуемый функционал; идеи, которые лежат в основе; полезные ссылки.

Решаемая проблема: как можно скорее зафиксировать мысль, чтобы её не забыть.


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

Для этого я использую отличное приложение Ship, которое пришло на замену более простому Gitscout.

Ship

При формализации задачи, я должен ответить на ряд важных для меня вопросов:

  • чем является данная задача: баг, новый функционал, улучшение, документация (GitHub labels)
  • на каком этапе требуется её выполнить (GitHub milestones)
  • в какой проект её следует включить (GitHub projects)
  • какой приоритет ей назначить (ZenHub estimate)

Решаемая проблема: быстрый доступ к задачам всех проектов в одном окне.


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

Здесь я попробовал несколько инструментов:

  • Wunderlist, в котором теперь я планирую чтение статей;
  • Todoist, от которого я отказался в пользу TickTick.

TickTick

Есть множество книг и техник на тему того, как управлять своим временем, и ещё больше софта для этих целей. Но всё это мусор, если у вас не будет элементарной дисциплины!

Решаемая проблема: планирование времени.


Особо хочу выделить один сервис, которым я пока не очень активно пользуюсь, но убеждён, что у него хороший потенциал. Это ZenHub, который начинал как небольшое расширение для браузера Chrome, но вырос в полноценное приложение “всё-в-одном”.

ZenHub

Интересные для меня возможности, которые предоставляет ZenHub:

  • вес задач
  • эпики
  • релизы
  • отчёты

Решаемая проблема: инструмент для полноценного управления проектами.

Коммуникация

Общение по email и/или во встроенном в GitHub трекере ошибок может быть не всегда удобным. Такие каналы коммуникации не подразумевают быстрой реакции на запросы пользователей.

Для оперативной обратной связи вполне может подойти Gitter, который изначально создавался с прицелом на тесную интеграцию с GitHub.

Gitter

Как правило, я создаю чат для проекта только на определённом этапе его зрелости - когда ценность этого проекта подтвердилась, а сам проект перешёл в состояние рабочего прототипа.

Решаемая проблема: вторая линия поддержки пользователей.


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

Для меня такой точкой доступа служит Slack.

Slack

Gitter тоже может выступать в этой роли, но в качестве корпоративного чата он мне не подходит. Альтернативой Slack вполне может быть HipChat, но всё-таки я остановил свой выбор на первом.

Решаемая проблема: централизовано отслеживать все транзакции по проекту.

Непрерывная интеграция

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

Scrutinizer

Список таких сервисов может быть совершенно разным в зависимости от стека технологий, используемых в проекте. Например, для проектов на Go я использую Exago и Go Report Card.

Решаемая проблема: сбор качественных метрик, обнаружение дефектов в коде на ранней стадии.


До появления Travis CI, в качестве сервера автоматизации я использовал Jenkins, который отнимал много времени и сил на обслуживание. Что же, сейчас про эту головную боль можно забыть, при этом сэкономив не только деньги на VPS, но и свой самый драгоценный ресурс.

Travis CI

На рынке существует большое количество подобных сервисов, например

Но я рекомендую сперва посмотреть, что есть на официальной площадке приложений:

Решаемая проблема: автоматизация тестирования и сборки.

Обеспечение надёжности

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

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

Bitbucket

Также, вы всегда можете установить Git непосредственно на свои сервера и дополнительно “прикрутить” к нему веб-приложение, например, одно из следующих:

Решаемая проблема: высокая доступность исходного кода.

Резюме

Я лишь мельком упомянул первую (база знаний: FAQ, документация, глоссарий) и третью (трекер ошибок) линии поддержки пользователей, потому что планирую рассказать про это более подробно в одной из следующих статей, посвященной обратной связи.

В качестве итога данной статьи я хотел бы зафиксировать следующие положения:

  1. Черновик должен быть всегда у вас под рукой для того, чтобы вы могли оперативно фиксировать в нём свои идеи.
  2. Систематизируйте работу со своими идеями: просеивайте их через “три сита”, расставляйте приоритеты.
  3. Планируйте своё время для работы с ними.
  4. Автоматизируйте рутину, избавляйте себя от бремени монотонной работы.
  5. Продумывайте негативные сценарии, минимизируйте риск точек отказа.

Постскриптум

Другой полезный инструментарий, не вошедший в данный обзор, можно найти в моих коллекциях: