По долгу службы, с некоторых пор, пришлось заняться написанием ТЗ на разработку. Когда передо мной только встала такая задача, как оказалось, все делали это в MS Word. Я по началу тоже попробовал писать ТЗ в доке, но не выдержал и недели. Уж не знаю, или Word — это зло, или я просто не умею его готовить, но факт остается фактом, бОльшую часть времени я, в силу своей аккуратности и щепетильности, занимался форматированием: то отступы в списках разъедутся, то межстрочные интервалы в разных местах разные, а уж про разрешение конфликтов совместного редактирования — я вообще молчу! Да и ТЗ предназначались для разработчиков, которые любят простой текст, системы контроля версий и сидят на разных операционных системах. И я озадачился поиском более подходящих инструментов. И вот что у меня получилось.
Метка: gitlab
Продолжение истории о инструментах сопровождения разработки.
Что-то давно я ничего не писал по этому поводу, хотя с момента второй части произошли существенные изменения 🙂
Если совсем коротко — то мы начали использовать redmine. Но это наверное не так интересно. Поэтому далее опишу как мы построили наш процесс. Возможно кому-то это будет интересным, а может еще и полезным.
До недавнего времени нашим основным способом просмотра кода был просмотр лога коммитов гит в исследуемой ветке, и, если надо, более детальное изучение кода непосредственно в исходниках, с включенным режимом blame history (когда в IDE показывется какие строчки кем и когда были написаны). И этот способ вполне имеет право на жизнь, когда разработчиков не много, они делают аккуратные небольшие коммиты — с этим можно жить.
В этой части будет обзор систем контроля версий, и способов управления правами доступа к репозиториям. Хотя не, обзора систем контроля версий не будет. Git и все.