Какую систему управления проектами лучше выбрать? Джерад Битнер (Jerad Bitner), искушенный разработчик и координатор проектов, поделился с читателями сайта Lullabot опытом своей работы с системами управления проектами. Так вот, в его проекте в качестве системы управления используется не что иное, как GitHub.
За годы работы над проектами Джераду довелось перепробовать множество систем управления. В той или иной степени им всегда чего-то не хватало, либо они были неудобны для использования и, в конце концов, доставляли массу неудобств. Если эти системы предлагали удобный функционал для менеджеров, то они, как правило, оказывались неудобными для разработчиков. Если они были удобны для разработчиков – дизайнеры разносили их в пух и прах. И, казалось, не было ни одной системы, которая отвечала бы нуждам всей команды.
Недавно для управления проектами Джерад и его команда начали использовать GitHub. Это было вызвано главным образом восторгом разработчиков по поводу его удобства для работы с кодом. И, на удивление всей команды, GitHub доказал свою надежность в управлении проектами. Даже дизайнеры начали применять его для некоторых своих проектов, что говорит об удачном дизайнерском решении системы. Предлагая удобный функционал для всех членов команды, GitHub постепенно становится наиболее востребованным инструментом для хостинга кода, управления проектами и упрощения системы коммуникаций на проекте.
Инструкция по применению
GitHub во многом ориентирован на разработчиков. Начиная работать с системой, первое, что видит разработчик, – это репозиторий. Помимо этого, GitHub автоматически показывает содержимое файла README, который находится в корне проекта. На самом деле, это довольно распространенная практика для ИТ-проектов, особенно с открытым исходным кодом, – иметь этот файл под рукой.
Файлы README могут быть представлены в разной форме. Так, например, разработчики в команде Джерада Битнера предпочитают использовать файлы с марк-дауновской разметкой. Использование расширения .md в файле README уже указывает на то, что GitHub представит файл с марк-дауновской разметкой. Более того, GitHub предлагает собственный вариант марк-дауновской разметки. Как только разработчики проекта впервые видят файл README, они незамедлительно получают отличное средство для работы с проектом. При составлении файла будьте лаконичны. Если требуется написать больше, чем несколько предложений, то лучше залинковать их с более детальной документацией в вики проекта. Вот несколько пунктов, которые следовало бы включить в файл README.
1. Краткий обзор проекта
Предоставьте краткое описание целей проекта и немного общей информации о проекте. Также не помешает включить в него ссылки для быстрого доступа, которые вы часто используете.
2. Информация о структуре директории
В корне репозитория обычно используется больше средств, чем только Drupal, поэтому будет полезно включить в файл краткое описание содержимого проекта. В команде Джерада обычно используют drush folder для символических ссылок и команд, а также для директории с патчами с их собственными README файлами.
3. Как начать разработку
Расскажите разработчикам о наиболее удобном способе влиться в проект. Например, так: «клонируйте этот репозиторий, создайте отдельную ветку для разработки функционала, запустите инсталлятор, загрузите копию базы данных... Кто бы ни просматривал pull request’ы, эти люди также должны позволять удалять клонированные ветки разработки из репозитория, как только они объединены в основную ветку.”
4. Путь к продвижению вашего кода
Было бы неплохо выделить ключевые аспекты процесса разработки, поскольку они могут меняться от проекта к проекту. Хотите ли вы клонировать ваш репозиторий и отправлять pull request’ы, создать отдельную ветку разработки и отправлять pull request’ы или коммитить сразу все изменения в основную ветку разработки? Сообщите разработчикам свои требования заранее, чтобы избежать недопонимания.
5. Среда разработки
Предоставьте информацию о среде для разработки, тестирования и продакшена, если они у вас есть. Также опишите процесс перехода между этими окружениями. Как убедиться, что ваш код уже готов к тестированию? Каков наилучший способ для копирования базы данных? Команде Джерада нравится устанавливать временные ссылки для каждой среды, поскольку это предоставляет разработчикам необходимую информацию с самого начала. Обратите внимание на пример команд, которые используются для типичных операций.
6. Ссылки на полезные источники информации
Обычно к таким ссылкам относятся:
вики проекта, где хранится детальная документация по проекту;
подробная информация о проекте – например, исходное техническое задание, логины и пароли для доступа к окружениям, заметки Scrum, чек-листы для запуска, и т.д.
Для Drupal-проектов, над которыми работают Джерад и его команда, они попытались создать шаблонные тексты, которые они постоянно используют для новых проектов и модифицируют их, когда находят более подходящие варианты. Просмотрите представленные варианты и, если они покажутся вам полезными, не стесняйтесь использовать их! Если вам покажется, что чего-то не хватает, либо у ваc появятся идеи, как их усовершенствовать, скопируйте их в отдельную ветку и отправьте Джераду свой pull request.
Работа с задачами в GitHub
В GitHub используется довольно простая система управления задачами и багтрекинга. Однако она достаточно гибкая, чтобы предоставлять эффективную систему управления целыми проектами, большими и маленькими. В GitHub есть задачи со взаимными ссылками, теги для прикрепления метаданных к вашим задачам, методы для прикрепления кода к вашим задачам и даже возможность создания ключевых событий для группировки ваших задач внутри фаз разработки проекта.
1. Обращения и ассоциации
Задачи могут быть связаны между собой с помощью значка # (например, #3) внутри другой задачи. Это удобно во многих отношениях. Во-первых, это позволяет упростить систему связей в системе. Нет необходимости беспокоиться о типе задачи (родительская/задача того же уровня/дочерняя задача). Тем не менее, есть несколько приемов, которые помогают сделать систему еще более удобной, если вы поймете принцип ее работы. Рассмотрим следующий пример.
Допустим, что вы создаете задачу для конкретного типа контента и одна из составляющих этого типа контента – таксономический словарь. Возможно, для составления словаря вы захотите создать отдельную задачу.
Таким образом, вы создаете задачу для типа контента – новости,
а затем вы создаете задачу для таксономического словаря и в описание задачи включаете ссылку на задачу с новостями.
Достаточно всего лишь поставить знак # (в нашем случае #4), и GitHub создаст ссылку на задачу с новостями и, кроме того, добавит обратную ссылку на первоначальную задачу!
Нельзя не обратить внимание, что статус связанной со ссылкой задачи можно видеть как часть самой ссылки. Это очень удобно для любого члена команды, который работает с новостной задачей. Они могут видеть статус ее «зависимости» (этот термин используется условно, поскольку в данном примере – это действительно зависимость, но так бывает не всегда).
2. Теги задач
Теги – это простой и эффективный способ добавлять описание к вашим задачам. Многие системы способны создавать поля и категории с различными значениями, чтобы предоставить вам полный контроль над описанием задачи. В GitHub используется простая система тегов, к тому же очень гибкая и эффективная.
По умолчанию в GitHub используется несколько тегов: баг, повторная запись о баге, расширение, неверный, вопрос и статус won't fix.
Эти примеры позволят вам разобраться, как начать использовать теги. Например, «баг» - это тип задачи, в то время как «won't fix» - это ее статус. Тегами могут быть совершенно любые слова, и, если они подобраны правильно, они сразу же дают понять любому разработчику, о каком типе тикета и каком разделе может идти речь, или какой статус у той или иной задачи.
Помимо того, что теги очень удобны для программистов, они также могут использоваться менеджерами проектов в качестве фильтров. Например, выбрав те или иные теги, можно просмотреть все задачи, которые с ними связаны, например, задачи с тегами «миграция», «таксономия» или «тип контента».
3. Добавление кода к существующей задаче
Pull request’ы являются отличным инструментом для совместной работы над кодом. Если вы не знакомы с принципом, вам будет полезно ознакомиться с демо о pull request’ах . Это простой и быстрый способ, который позволяет разработчикам создать новую копию проекта (путем полного клонирования, либо продолжая работу в рамках проекта) и предложить свои модификации для существующего кода или внести вклад в разработку кода. Они также позволяют другим членам команды просматривать новый код, добавлять свои комментарии и затем принимать решение о необходимости внесения нового кода в основную базу. Таким образом, pull request’ы действительно очень полезны и удобны для командной работы, поскольку позволяют всем участникам команды следить за циклом проекта со всеми актуальными изменениями.
Одним словом, pull request’ы – это удобный инструмент для совместной работы, который помогает поддерживать состояние кода в соответствии с ожиданиями каждого участника команды. Есть небольшой нюанс: объединение больших кусков кода занимает достаточно много времени, поэтому рекомендуется планировать работу соответственно. Но есть и существенный плюс. Вы обнаружите баги раньше, чем они попадут в основную ветку разработки проекта.
При работе с pull request’ами следует учитывать, что, когда вы его создаете, работая с веб-интерфейсом GitHub, в действительности система создает новую задачу. И пусть вы можете сослаться на конкретную задачу в своем pull request, но он все равно остается самостоятельной задачей. Однако, используя удобную командную строку, которая называется Hub, можно превращать задачи в pull request’ы! Эта система очень удобна для сохранения обсуждений и кода в одном месте, вместо того чтобы заниматься множественными задачами, которые по сути одинаковы.
Ключевые события
В GitHub используется механизм для создания ключевых событий, что типично для систем управления проектами подобного типа. Когда вы создаете новое событие, оно состоит из названия, описания и календаря для выбора даты наступления.
Вы можете видеть уровень прогресса каждой фазы разработки проекта.
Обычно планируют одну фазу проекта, но ничто не мешает вам планировать ключевые события для последующих фаз, вплоть до окончания проекта.
Тикеты для их создания берутся из списка требований проекта. Фактически это может быть любой тикет, который не используются для описания фазы проекта.
Huboard
Системе трекинга задач в GitHub не хватает механизма расстановки приоритетов задач. В этом случае можно использовать лейблы с приоритетом задачи, как например, Высокий (High), Средний (Medium), Низкий (Low), но, возможно вы предпочтете упорядоченный список с наиболее важными задачами на вершине списка.
Зайдите в систему Huboard, которая предлагает вам удобный интерфейс в стиле канбан (похожем на Trello), который задействует все возможности GitHub API. Вы смотрите на свои задачи в GitHub, но уже с другим интерфейсом. Инструкции по его установке достаточно подробные, поэтому нет смысла останавливаться на них повторно. Однако стоит упомянуть, что его достаточно просто и быстро развернуть на платформе Heroku, и это не потребует больших затрат на поддержку. Используя Huboard, вы получаете возможность видеть приоритет задач на неделю, таким образом, разработчики всегда видят, чем они должны заняться далее.
Логины
Некоторые системы управления проектами требуют нового логина для каждого нового экземпляра программного обеспечения. Например, если у вас есть два разных клиента, которые используют одну и ту же систему управления проектами, то, возможно, вам придется запомнить две различные комбинации логина и пароля и вы не сможете легко переключаться между учетными записями. GitHub предоставляет пользователям доступ ко всем проектам и репозиториям, к которым у вас есть доступ, без необходимости создавать несколько учетных записей.
Система Github не содержит ничего лишнего, но вам может показаться, что в ней не хватает привычных и удобных вам опций. Однако, к счастью, команда разработчиков GitHub постоянно работает над функционалом системы и достаточно часто публикует все обновления в своем блоге .
Подводя итог, стоит отметить, что GitHub – это отличная система управления проектами для технически подкованных специалистов, в то время как остальным она может показаться не очень удобной и даже несколько запутанной.
Источник
16 лет dev.by — «дефолтный» источник информации о беларусском ИТ
Какую систему управления проектами лучше выбрать? Джерад Битнер (Jerad Bitner), искушенный разработчик и координатор проектов, поделился с читателями сайта Lullabot опытом своей работы с системами управления проектами. Так вот, в его проекте в качестве системы управления используется не что иное, как GitHub.
За годы работы над проектами Джераду довелось перепробовать множество систем управления. В той или иной степени им всегда чего-то не хватало, либо они были неудобны для использования и, в конце концов, доставляли массу неудобств. Если эти системы предлагали удобный функционал для менеджеров, то они, как правило, оказывались неудобными для разработчиков. Если они были удобны для разработчиков – дизайнеры разносили их в пух и прах. И, казалось, не было ни одной системы, которая отвечала бы нуждам всей команды.
Недавно для управления проектами Джерад и его команда начали использовать GitHub. Это было вызвано главным образом восторгом разработчиков по поводу его удобства для работы с кодом. И, на удивление всей команды, GitHub доказал свою надежность в управлении проектами. Даже дизайнеры начали применять его для некоторых своих проектов, что говорит об удачном дизайнерском решении системы. Предлагая удобный функционал для всех членов команды, GitHub постепенно становится наиболее востребованным инструментом для хостинга кода, управления проектами и упрощения системы коммуникаций на проекте. 
а затем вы создаете задачу для таксономического словаря и в описание задачи включаете ссылку на задачу с новостями.
Достаточно всего лишь поставить знак # (в нашем случае #4), и GitHub создаст ссылку на задачу с новостями и, кроме того, добавит обратную ссылку на первоначальную задачу!
Нельзя не обратить внимание, что статус связанной со ссылкой задачи можно видеть как часть самой ссылки. Это очень удобно для любого члена команды, который работает с новостной задачей. Они могут видеть статус ее «зависимости» (этот термин используется условно, поскольку в данном примере – это действительно зависимость, но так бывает не всегда).
2. Теги задач
Теги – это простой и эффективный способ добавлять описание к вашим задачам. Многие системы способны создавать поля и категории с различными значениями, чтобы предоставить вам полный контроль над описанием задачи. В GitHub используется простая система тегов, к тому же очень гибкая и эффективная.
По умолчанию в GitHub используется несколько тегов: баг, повторная запись о баге, расширение, неверный, вопрос и статус won't fix.
Эти примеры позволят вам разобраться, как начать использовать теги. Например, «баг» - это тип задачи, в то время как «won't fix» - это ее статус. Тегами могут быть совершенно любые слова, и, если они подобраны правильно, они сразу же дают понять любому разработчику, о каком типе тикета и каком разделе может идти речь, или какой статус у той или иной задачи.
Помимо того, что теги очень удобны для программистов, они также могут использоваться менеджерами проектов в качестве фильтров. Например, выбрав те или иные теги, можно просмотреть все задачи, которые с ними связаны, например, задачи с тегами «миграция», «таксономия» или «тип контента».
3. Добавление кода к существующей задаче
Pull request’ы являются отличным инструментом для совместной работы над кодом. Если вы не знакомы с принципом, вам будет полезно ознакомиться с демо о pull request’ах . Это простой и быстрый способ, который позволяет разработчикам создать новую копию проекта (путем полного клонирования, либо продолжая работу в рамках проекта) и предложить свои модификации для существующего кода или внести вклад в разработку кода. Они также позволяют другим членам команды просматривать новый код, добавлять свои комментарии и затем принимать решение о необходимости внесения нового кода в основную базу. Таким образом, pull request’ы действительно очень полезны и удобны для командной работы, поскольку позволяют всем участникам команды следить за циклом проекта со всеми актуальными изменениями.
Одним словом, pull request’ы – это удобный инструмент для совместной работы, который помогает поддерживать состояние кода в соответствии с ожиданиями каждого участника команды. Есть небольшой нюанс: объединение больших кусков кода занимает достаточно много времени, поэтому рекомендуется планировать работу соответственно. Но есть и существенный плюс. Вы обнаружите баги раньше, чем они попадут в основную ветку разработки проекта.
При работе с pull request’ами следует учитывать, что, когда вы его создаете, работая с веб-интерфейсом GitHub, в действительности система создает новую задачу. И пусть вы можете сослаться на конкретную задачу в своем pull request, но он все равно остается самостоятельной задачей. Однако, используя удобную командную строку, которая называется Hub, можно превращать задачи в pull request’ы! Эта система очень удобна для сохранения обсуждений и кода в одном месте, вместо того чтобы заниматься множественными задачами, которые по сути одинаковы.
Вы можете видеть уровень прогресса каждой фазы разработки проекта.
Обычно планируют одну фазу проекта, но ничто не мешает вам планировать ключевые события для последующих фаз, вплоть до окончания проекта.
Тикеты для их создания берутся из списка требований проекта. Фактически это может быть любой тикет, который не используются для описания фазы проекта.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.