Какие минусы храниения в репозитории вместе с кодом и технической документации:
например
* краткого описания со ссылками на разые знания
* краткой инструкции для программистов
* краткой инструкции для DevOps
* контрактов (напрмер json swagger/OpenApi) с внешними/внутренними REST/other — сервисами
Re: Хранение доп. материалов в репозитории исходников
Здравствуйте, SomeOne_TT, Вы писали:
SO_>Здравствуйте, nikda, Вы писали:
N>>Какие минусы храниения в репозитории вместе с кодом и технической документации:
SO_>Но зачем, если на проекте есть вики? SO_>А если нет — это неправильно.
Нужную статью в wiki — нужно тоже как-то найди и правильно wiki вести и актуализировать.
А так есть например, формальный OpenApi-контракт — и сразу код его реализующий. И видно что когда и как менялось.
Re[2]: Хранение доп. материалов в репозитории исходников
N>>Какие минусы храниения в репозитории вместе с кодом и технической документации:
SO_>Но зачем, если на проекте есть вики?
Например, чтобы можно было взять скопом все необходимое для автономной работы с проектом.
Если, например, человек хочет какое-то время поработать на своем ноуте удаленно, или едет с ноутом в командировку, и т.п.
Re: Хранение доп. материалов в репозитории исходников
N>Какие минусы храниения в репозитории вместе с кодом и технической документации: N>например
Минус может быть, что такие материалы трудно мержить. Например, если документация в pdf, и два разработчика внесли изменения — им может быть трудно их состыковать.
Но это минус несущественный, проблема решаемая.
Re: Хранение доп. материалов в репозитории исходников
Здравствуйте, nikda, Вы писали:
N>Какие минусы храниения в репозитории вместе с кодом и технической документации:
В какой то момент может оказаться, что одному проекту и/или команде будут соответствовать несколько репов.
Еще техдокументация может понадобиться stakeholders, а вот давать доступ к репу с исходниками им не всегда стоит. Та же история с инструкциями для саппорта, крупными клиентами и т.п.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, nikda, Вы писали:
N>>Какие минусы храниения в репозитории вместе с кодом и технической документации:
НС>В какой то момент может оказаться, что одному проекту и/или команде будут соответствовать несколько репов.
НС>Еще техдокументация может понадобиться stakeholders, а вот давать доступ к репу с исходниками им не всегда стоит. Та же история с инструкциями для саппорта, крупными клиентами и т.п.
Я скорее имел в виду тему про хранение контрактов OpenApi или любых других контрактов — для фиксации и слежением за историей их изменений. Пусть где-то в больших документах хранится то, что нужно для "публичного" доступа внутри компании. А в репозитории исходников — то что нужно разработчикам дополнительно.
Re[3]: Хранение доп. материалов в репозитории исходников
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, nikda, Вы писали:
N>>Я скорее имел в виду тему про хранение контрактов OpenApi
НС>Зачем их хранить? Их динамически надо строить и отдавать прям из сервиса.
Сторонник контрактов, т.е. тех, что использует моё приложение/сервис.
Что бы можно было контролировать актуальность контракта стороннего сервиса.
N>> или любых других контрактов
НС>Каких? Если речь про клиентские библиотеки, то да, их желательно хранить рядом с серверным кодом. И выкладывать бинарники в публичный фид.
Например WSDL, XSD контрагентов.
Re[5]: Хранение доп. материалов в репозитории исходников
Здравствуйте, nikda, Вы писали:
N>Сторонник контрактов, т.е. тех, что использует моё приложение/сервис. N>Что бы можно было контролировать актуальность контракта стороннего сервиса.
Описание REST методов в языке программирования это точно такой же контракт, ничем не хуже OpenAPI спецификации.
НС>>Каких? Если речь про клиентские библиотеки, то да, их желательно хранить рядом с серверным кодом. И выкладывать бинарники в публичный фид. N>Например WSDL, XSD контрагентов.
