Как и где хранить техническую документацию?

Привёл в порядок инфраструктуру в Компании и пришла пора документации. В каком виде хранить и где?
  • Вопрос задан
  • 4867 просмотров
Пригласить эксперта
Ответы на вопрос 15
MetaAbstract
@MetaAbstract
Архитектор информационных систем и баз данных. Ful
DokuWiki
Ответ написан
Комментировать
DDDsa
@DDDsa
Хороший подход — docs as code.
Мы ведём все документы в git-репозиториях, в формате Markdown. Исходники обёрнуты в Foliant, который может в любой момент из md собрать PDF, docx, сайт, гугл-док или что угодно. Например, многие проекты с документацией автоматически собираются в базу знаний при помощи GitLab-CI. При каждом пуше изменений в репозиторий сайт пересобирается и мы уверены, что там всегда свежие доки. А как только менеджер просит готовый документ — можно тут же собрать PDF, с коропоративным лого и т д.

При этом исходники всегда лежат в plain-text в репозиториях, что даёт возможность работать над доками вдвоём и втроём, со всеми взрослыми фишками вроде девелоп и мастер веток, фичей, релизов, как будто это код.
Ответ написан
Комментировать
@q2digger
никого не трогаю, починяю примус
Knowlage base - спейс в корп. Confluence
Инфраструктуру, кабельную документация и описание серверов-свитчей - Racktables.
Ответ написан
eduardtibet
@eduardtibet
Technical Writer / Documentation Engineer
Если не хотите тыкать пальцем в небо, а нужен системный подход без факапов, начните изучать тему отсюда: Как лучше сделать документацию компании? и далее по ссылкам в том посте.

P.S. Неоднократно замечаю интересный факт. Все советуют решение, о котором вроде бы слышали или которое работает конкретно у них, но никто не задается главным вопросом: а какая цель у ТС? Какие входные условия у ТС? Участники треда, вы понимаете, что выбор инструмента/подхода - это не выбор из А, B, C. Это, в первую очередь, определение цели (они могут различаться на 180 град.), анализ входных условий и только потом выбор инструмента/подхода. Если у конкретного участника этого топика работает инструмент/подход, который приносит ему пользу, то это совсем НЕ означает, что такой же подход с таким же успехом будет обязательно работать у топикстартера.
Ответ написан
Комментировать
@MechanID
Админ хостинг провайдера
моя эволюция:
1 куча txt
2 redmine
3 confluence
Ответ написан
@Kirill-Gorelov
С ума с IT
docsify + gist.github.com
Ответ написан
Комментировать
@other_letter
Тут многие пишут конкретные решения.
А я советую любой WIKI. Какой душе угодно. Сейчас Вы не поймёте прелестей совместной работы и прочего, что даст Вам продукт посерьёзнее.
А так - ветки есть, связность без проблем, версионность опять же. Совместная работа, комменты - да всё это в любом известном мне вики-движке есть
Ответ написан
Комментировать
@vlarkanov
confluence
Ответ написан
Комментировать
Francyz
@Francyz
Photographer & SysAdmin
Доки во всяких Wiki.
Файлы конфигов в Git (и аналогах), можно откатиться и т.д., все по рукой, видно когда что менялось.
Схема можно в банальном Visio.

Раньше инфу по компам и принтерам держал в связке GLPI+FussionInventory, там же кстати была база FAQ
Ответ написан
Комментировать
CityCat4
@CityCat4
Внимание! Изменился адрес почты!
redmine. В нем есть и хранилище документов и вики. Схемы в Visio. Конфиги и прочую текстовую байду - в SVN
Ответ написан
Комментировать
@lonelymyp
Хочу вылезти из минуса по карме.
зоопарк doc файлов на ftp
плачу и рыдаю
написал чтоб просто пожаловаться.
Ответ написан
Комментировать
hempy80
@hempy80
Внесистемный администратор
Confluence, Netbox
Ответ написан
Комментировать
@zxosa
Любой Wiki + основополагающие вещи в бумаге обязательно (исполнительная документация и другие планы и схемы, к примеру)
Ответ написан
Комментировать
@ekopiy
Sphinx+тема readthedocs+git+иногда интеграция plantuml отлично подходят для документирования исходников, api, программных продуктов, веб-интерфейсов, алгоритмов, да и просто текста. Де факто стандарт для ИТ, очень удобный и красивый
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы