Size: a a a

DocOps-сообщество

2019 August 24

V

Vanger in DocOps-сообщество
Nikolaj Potashnikov
Слушайте, а почему? У нас очень стабильно и хорошо работает. Т.е. единственное, почему мы используем git, это PR'ы, т.е. возможность github-flow и иных flow. Но там где нужно просто организовать общую работу над документами, особенно с заказчиком, все работает прекрасно
ну я не говорю тут за документацию. когда проекты маленькие то ничего плохого нет
источник

V

Vanger in DocOps-сообщество
а вот когда исходников с модулями становится на несколько сот мегабайт, и работают с ним не одна группа. Вот тогда начинается боль
источник

V

Vanger in DocOps-сообщество
Nikolaj Potashnikov
Слушайте, а почему? У нас очень стабильно и хорошо работает. Т.е. единственное, почему мы используем git, это PR'ы, т.е. возможность github-flow и иных flow. Но там где нужно просто организовать общую работу над документами, особенно с заказчиком, все работает прекрасно
ну и плюсы гита вы описали. А это уберфичи, которые в разы упрощают мержи и ветвление
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
в этом случае, ясно.. когда дырку в деревяшке надо просверлить, то шуруповерт,  а когда в армированном битоне, то шуруповерт — боль
источник

V

Vanger in DocOps-сообщество
Nikolaj Potashnikov
в этом случае, ясно.. когда дырку в деревяшке надо просверлить, то шуруповерт,  а когда в армированном битоне, то шуруповерт — боль
ну у нас проект начинался когда гит даже не пахло
источник

V

Vanger in DocOps-сообщество
тогда были разные cvs и еще пару небольших вещей.. свн был глотком воздуха
источник

НН

Нац Нац in DocOps-сообщество
Vanger
тогда были разные cvs и еще пару небольших вещей.. свн был глотком воздуха
МеРкУрИаЛ
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
такая же история... vcs -> svn... но сейчас svn для исходного кода не используется, конечно, никогда
источник

ДБ

Дмитрий Башкирцев in DocOps-сообщество
а гидраргирум на мелких проектах уже шиза
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
Нац Нац
МеРкУрИаЛ
Кстати, есть интервью, по-моему, с Антоном Архиповым, где он говорит... что git, что mercurial
источник

V

Vanger in DocOps-сообщество
Нац Нац
МеРкУрИаЛ
это было в 2005 если не ошибаюсь, мы начали чуть раньше)
источник
2019 August 25

СФ

Семён Факторович in DocOps-сообщество
источник

iv

iakov v in DocOps-сообщество
Nikolaj Potashnikov
Кстати, есть интервью, по-моему, с Антоном Архиповым, где он говорит... что git, что mercurial
у git и hg есть мелкие различия; мы в компании сейчас в процессе миграции с hg на git, и местами способы миграции неочевидны, хотя на небольших репозиториях и при «обычных» условиях вроде бы что git, что hg
источник
2019 August 26

B

Borodalo in DocOps-сообщество
Доброго дня.

Подскажите, пожалуйста, существует ли нечто с наличием шаблонов под различные профили.

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


Или нужно пилить самому?
источник

NV

Nick Volynkin in DocOps-сообщество
Borodalo
Доброго дня.

Подскажите, пожалуйста, существует ли нечто с наличием шаблонов под различные профили.

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


Или нужно пилить самому?
Не видят — это значит, что какие-то блоки свёрнуты, на другой странице, или вообще недоступны без авторизации под нужной учёткой?
источник

B

Borodalo in DocOps-сообщество
Вовсе недоступны для просмотра.
Хотя "свёрнуты" тоже интересно для посмотреть
источник

A

Angela in DocOps-сообщество
Borodalo
Доброго дня.

Подскажите, пожалуйста, существует ли нечто с наличием шаблонов под различные профили.

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


Или нужно пилить самому?
в DITA есть профилирование контента под разные продукты/роли/сборки и тд
источник

B

Borodalo in DocOps-сообщество
Angela
в DITA есть профилирование контента под разные продукты/роли/сборки и тд
спасиб
источник

NV

Nick Volynkin in DocOps-сообщество
Вариант 1. Берёте любой генератор статических сайтов, в котором есть условия и/или инклюды.  Контент «только для Х» выносите в отдельные блоки, при сборке инклюдите их по условию. Получается либо один сайт с разным контентом на разных страницах, либо разные сайты. К этому можно прикручивать аутентификацию, если нужно совсем запретить доступ.
источник

NV

Nick Volynkin in DocOps-сообщество
Вариант 2. Берёте Confluence, в нём контент «только для Х» выносите в отдельные документы, в них выставляете права для нужных пользователей и групп. Там есть авторизация и интеграция с LDAP. Потом в общий документ включаете эти кусочные документы.
источник