- PVSM.RU - https://www.pvsm.ru -
Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.
За это время я перепробовал разные рабочие процессы, и хочу поделиться советами, как построить эффективный и прагматичный рабочий процесс по созданию и сопровождению качественного ПО, который можно применять в любом проекте.
Есть много признаков качественного ПО: надёжность, устойчивость, модульность, безопасность, производительность, масштабируемость, удобство в использовании, тестировании и сопровождении. И много других признаков, в зависимости от типа приложения. В этой статье я сосредоточусь на таких свойствах:
Предлагаю строить прагматичный рабочий процесс с применением open source-инструментов, помогающих выполнять и автоматизировать многие задачи.
Если вы работает в open source-проекте, то наверняка хотите публиковать свой Github-проект. Git и Github полностью изменили способ разработки OSS, де-факто превратившись, соответственно, в стандартный язык версионирования и площадку для сотрудничества.
Официально предлагаемый Github’ом рабочий процесс называется github flow. Он прекрасно описан на сайте [1]. Этого процесса, с небольшими вариациями, придерживается большинство open source-проектов.
Github Flow очень гибок в том смысле, что он не диктует вам, как нужно релизить и документировать изменения, какую стратегию слияния использовать, когда принимать pull request'ы, какие инструменты применять, каким стандартам коммитов следовать или что нужно рецензировать перед принятием pull request'а. Всё это отдано на ваше усмотрение, и правильно сделано, поскольку не существует универсальных решений, подходящих всем командам.
Дальше я приведу список рекомендаций на основе моего опыта.
По большей части (почти исключительно) я пишу на JavaScript, многие упомянутые мной инструменты являются частью JS-экосистемы, но сами идеи применимы в любом языке.
В сентябре 2016 появилась фича Projects. Это инструмент, позволяющий создавать доски в стиле Kanban для упорядочивания, приоритезации и отслеживания работы на уровне репозитория и организации. Если у вас есть затруднения с использованием Github, настоятельно рекомендую освоить Projects для организации и обмена информацией о приоритетах проекта и текущих усилиях.
Подробнее [2]
Github имеет превосходные возможности по фильтрации. Если вы работаете над open source-проектом, то наверняка заинтересованы в привлечении других участников, а также в том, чтобы им было удобно. Если помечать свои задачи тегами, разработчикам легче будет ориентироваться в списке, это сэкономит им время и облегчит работу над проектом.
Не пожалейте времени на написание Guthub-шаблонов для pull request'ов и информирования о проблемах. Это заставит других разработчиков — или хотя бы поможет им — слать отчёты о багах и запрашивать создание фич неким стандартным способом, прикладывая всю необходимую вам информацию.
Подробнее [3]
Основные советы по отчётам о багах:
Прежде чем отправлять информацию о проблеме:
Отчёты о багах должны содержать:
Общие рекомендации по pull request'ам:
Консоль — ваш друг. По моему опыту, освоение работы с Github через командную строку — лучшая трата времени, когда работаешь с open source-технологиями. Да, существует много хороших графических интерфейсов, но все они менее гибки в использовании. Кроме того, есть инструменты только под командную строку, которые сильно упрощают жизнь и повышают эффективность разработки:
Всегда определяйте и соблюдайте ясные стандарты написания коммит-сообщений. Вот некоторые рекомендации:
gitk
или git log –oneline
, то поймёте, почему.Кроме того, для улучшения генерирования журнала изменений настоятельно рекомендую распределять сообщения по категориям (scope). Тогда ваши журналы изменений будут информативнее. Прекрасный пример: соглашения о коммитах и генерирование журналов изменений в AngularJS [6].
Для написания удобного в сопровождении кода очень важно определять стандарты оформления и соблюдать их в прекоммит-хуках (pre-commits hooks). Стандарты помогут поддерживать единообразие кода вне зависимости от того, кто его пишет, а также помогут принимать и сопровождать код, написанный кем-то другим.
Я рекомендую использовать Prettier и StandardJS, но это дело вкуса, существует множество других решений; к тому же, вы можете сделать что-то своё. Главное, следуйте выбранным стандартам оформления кода, это пойдёт на пользу.
typicode/husky [7] — прекрасный инструмент для конфигурирования прекоммит-хуков.
Очень желательно автоматизировать функциональные тесты и проверки безопасности и стиля оформления кода в каждом pull request'е. Вряд ли вы захотите всё это делать вручную. Можно быстро сконфигурировать сервер непрерывной интеграции, вроде TravisCI, чтобы автоматически прогонять тематическую ветку через тесты после отправки каждого pull request'а. Также можно сконфигурировать Github, чтобы он не позволял разработчику присоединять pull request'ы, если те не прошли тесты. При сбое тестов Github покажет автору сообщение, чтобы он исправил свои pull request'ы.
Подробнее [8].
Github позволяет защищать мастер-ветку от прямых коммитов, принудительных push’ей и перебазирования. Это очень важно, когда работаешь с кем-то над проектом. Кроме того, обязательно требуйте проводить ревизию кода, прежде чем объединять его с мастер-веткой. Это задаётся во вкладке настроек каждого репозитория.
Защитив мастер-ветку и включив принудительную ревизию, вы будете знать, что нежелательный код вряд ли попадёт в мастер и что никто в команде не подставит остальных, изменив Git-историю мастер-ветки или запушив непроверенный код.
Много споров о том, что правильно: объединять, сквошить (squash) или перебазировать. Я считаю, что лучше всего сквошить, потому что:
Чтобы успешно выстроить рабочий процесс на основе сквошинга, необходимо все pull request'ы категоризировать по конкретным фичам, исправлениям багов или рутинным задачам.
Семантическое версионирование, Github-теги, релизы и автоматизированные журналы изменений
Версионирование играет огромную роль, особенно в open source-проектах, многие из которых будут зависеть от вашего ПО. Семантическое версионирование всем облегчит жизнь, потому что люди, лишь посмотрев на номер версии, будут знать, когда именно были внесены критические изменения, или содержит ли версия новые фичи или исправления багов.
Учитывая шаблон MAJOR.MINOR.PATCH, увеличивайте:
В качестве расширений шаблона MAJOR.MINOR.PATCH можно использовать дополнительные метки для пререлизов и сборок.
Помимо изменения версии package.json, рекомендую для каждой версии генерировать git-тег.
Подробнее [9].
Спецификация Conventional Commits подразумевает при написании коммит-сообщений соблюдение простого стандартизированного соглашения. Оно увязано с соглашением SemVer, которое просит разработчиков описывать в коммит-сообщениях все фичи, исправления и критические изменения. Соблюдая соглашение, мы создаём стандартный язык, упрощающий отладку в различных проектах.
Подробнее [10].
Автоматизировать этот процесс поможет TravisCI [11].
Также обратите внимание на эти пакеты: dominique-mueller/automatic-release [12], semantic-release/semantic-release [13].
Не обязательно использовать ветки релизов, как это предлагается в рамках Git Flow. Можно брать артефакты развёртывания из Git-тегов. Здесь описано, как с помощью TravisCI развернуть Git-теги в heroku [14]. Это очень просто, нужно лишь для атрибута тегов задать значение true. Такое поведение можно реализовать с помощью любого другого CI-сервера.
Для среды разработки можно настроить хук, который развёртывает последний мастер-коммит. А для сред комплектов (feature environments) можно использовать и не такие долгоживующие ветки; при желании, для каждого PR-запроса вы можете предоставлять временную тестовую среду, но такой подход сложнее, да и не является обязательным.
Очень удобный способ отслеживания активности в ваших Github-репозиториях из места, идеально подходящего для взаимодействия с командой: простой поток уведомлений в одном или нескольких чатах. К слову, в чатах вы можете делать и многое другое, в 2013-м на Github появился термин ChatOps, подробнее о нём рассказывается здесь [15].
Нам приходится регулярно тратить много времени на актуализацию зависимостей. Это идеальная задача для автоматизации. Существует много инструментов, помогающих поддерживать зависимости «свежими», автоматически создавая в проекте pull request'ы с последними версиями. Эти запросы будут прогнаны через автоматизированные нерегрессионные тесты, и если пройдут успешно, то можно надеяться, что код после объединения будет работать нормально. Будьте осторожны с изменениями уровня старших версий, дважды всё проверяйте.
Пара полезных инструментов: greenkeeper.io [16] и david-dm.org [17].
Open source-разработчики создали много полезных расширений, улучшающих работу с интерфейсом Github’а. Например:
Другие расширения: GitHub Browser Extensions [46].
На Kikobeats/awesome-Github [47] есть ещё инструменты для улучшения вашего рабочего процесса.
Github и методики разработки open source ПО постоянно развиваются, поэтому держите руку на пульсе новейших тенденций и инструментов, отслеживая Github-новости и соблюдая стандарты вашего сообщества. Прекрасный источник информации — Youtube-канал GitHub Training & Guides [48].
Автор: AloneCoder
Источник [49]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/open-source/281003
Ссылки в тексте:
[1] на сайте: https://guides.github.com/introduction/flow/
[2] Подробнее: https://help.github.com/articles/tracking-the-progress-of-your-work-with-project-boards/
[3] Подробнее: https://blog.github.com/2016-02-17-issue-and-pull-request-templates/
[4] hub.github.com: https://hub.github.com/
[5] github.com/tj/git-extras: https://github.com/tj/git-extras
[6] соглашения о коммитах и генерирование журналов изменений в AngularJS: https://gist.github.com/stephenparish/9941e89d80e2bc58a153#_blank
[7] typicode/husky: https://github.com/typicode/husky
[8] Подробнее: https://docs.travis-ci.com/user/pull-requests/
[9] Подробнее: https://semver.org/
[10] Подробнее: https://conventionalcommits.org/
[11] TravisCI: https://docs.travis-ci.com/user/deployment/releases/
[12] dominique-mueller/automatic-release: https://github.com/dominique-mueller/automatic-release
[13] semantic-release/semantic-release: https://github.com/semantic-release/semantic-release
[14] Здесь описано, как с помощью TravisCI развернуть Git-теги в heroku: https://docs.travis-ci.com/user/deployment/heroku/
[15] здесь: https://www.youtube.com/watch?v=NST3u-GjjFw
[16] greenkeeper.io: https://greenkeeper.io/
[17] david-dm.org: https://david-dm.org/
[18] GitHub Avatars: https://github.com/anasnakawa/chrome-GitHub-avatars
[19] chrome: https://chrome.google.com/webstore/detail/avatars-for-GitHub/pgjmdbklnfklcjfbonjfkdhaonlfogbb
[20] GitHub Awesome Autocomplete: https://github.algolia.com/
[21] chrome: https://chrome.google.com/webstore/detail/GitHub-awesome-autocomple/djkfdjpoelphhdclfjhnffmnlnoknfnd
[22] firefox: https://addons.mozilla.org/en-US/firefox/addon/GitHub-awesome-autocomplete/
[23] GitHub Categoric: https://github.com/ozlerhakan/categoric
[24] chrome: https://chrome.google.com/webstore/detail/GitHub-categoric/gbfpmfhnfmobaichcfnhdobencecomhg
[25] GitHub Hovercard: https://github.com/Justineo/GitHub-hovercard
[26] chrome: https://chrome.google.com/webstore/detail/GitHub-hovercard/mmoahbbnojgkclgceahhakhnccimnplk
[27] firefox: https://addons.mozilla.org/en-US/firefox/addon/GitHub-hovercard/
[28] GitHub Isometric Contributions: https://github.com/jasonlong/isometric-contributions
[29] chrome: https://chrome.google.com/webstore/detail/isometric-contributions/mjoedlfflcchnleknnceiplgaeoegien?hl=en&gl=US
[30] safari: https://github.com/jasonlong/isometric-contributions/blob/master/safari/isometric-contributions.safariextz?raw=true
[31] GitHub Linker: https://github.com/octo-linker/chrome-extension
[32] chrome: https://chrome.google.com/webstore/detail/octo-linker/jlmafbaeoofdegohdhinkhilhclaklkp
[33] GitHub Octotree: https://github.com/buunguyen/octotree
[34] chrome: https://chrome.google.com/webstore/detail/octotree/bkhaagjahfmjljalopjnoealnfndnagc
[35] safari: https://github.com/buunguyen/octotree#_blank
[36] firefox: https://addons.mozilla.org/en-US/firefox/addon/octotree/
[37] opera: https://addons.opera.com/en/extensions/details/octotree/
[38] GitHub Selfies: https://github.com/thieman/GitHub-selfies
[39] chrome: https://chrome.google.com/webstore/detail/GitHub-selfies/ldnpkdnkgkogfnahcnldaedcoadjbkbl
[40] GitHub Stars Tagger: https://github.com/artisologic/GitHub-stars-tagger
[41] chrome: https://chrome.google.com/webstore/detail/GitHub-stars-tagger/aaihhjepepgajmehjdmfkofegfddcabc
[42] Github NPM Hub: https://github.com/zeke/npm-hub
[43] chrome: https://chrome.google.com/webstore/detail/npm-hub/kbbbjimdjbjclaebffknlabpogocablj
[44] Github vscode-icons: https://github.com/dderevjanik/Github-vscode-icons
[45] chrome: https://chrome.google.com/webstore/detail/Github-vscode-icons/hoccpcefjcgnabbmojbfoflggkecmpgd
[46] GitHub Browser Extensions: https://github.com/showcases/GitHub-browser-extensions
[47] Kikobeats/awesome-Github: https://github.com/Kikobeats/awesome-Github
[48] Youtube-канал GitHub Training & Guides: https://www.youtube.com/githubguides
[49] Источник: https://habr.com/post/359246/?utm_campaign=359246
Нажмите здесь для печати.