Size: a a a

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

2018 November 10

NV

Nick Volynkin in DocOps-сообщество
Ekaterina Lysenko
Коллеги, привет!
Сталкивались ли вы с выбором единого решения для крупных разнонаправленных, но в рамках IT отрасли (совсем бекенд и разработка железа; контент продукты и т.п.), в части документирования продуктов и технических требований.
Общий список задач:
- подготовка тех протоколов для корпоративного использования с вариантами их последующей выгрузки (с сохранением разметки) для внешних структур;
- подготовка продуктовых решений, включая описание userstory, прототипирования интерфейсов...
- формирование схем, включая bpmn, sequence;
- таск трекер с возможностью интеграции с гитом.

Atlassian не предлагать!

Буду очень признательна за предложения!!!
а нужно ли управление доступом: разрешать определённым людям или группам просмотр и редактирование страниц?
источник

NV

Nick Volynkin in DocOps-сообщество
или редактированием управлять тоже через гит (пуллреквесты, защищённые ветки)? Но тогда вопрос про доступ на чтение остаётся
источник

EL

Ekaterina Lysenko in DocOps-сообщество
Nick Volynkin
или редактированием управлять тоже через гит (пуллреквесты, защищённые ветки)? Но тогда вопрос про доступ на чтение остаётся
Считай, что внутри компании все друг-другу открыты и проблем в этих вопросах нет ☺️
источник

I

Igor in DocOps-сообщество
Какая-нибудь wiki подойдёт
источник

NV

Nick Volynkin in DocOps-сообщество
Ekaterina Lysenko
Коллеги, привет!
Сталкивались ли вы с выбором единого решения для крупных разнонаправленных, но в рамках IT отрасли (совсем бекенд и разработка железа; контент продукты и т.п.), в части документирования продуктов и технических требований.
Общий список задач:
- подготовка тех протоколов для корпоративного использования с вариантами их последующей выгрузки (с сохранением разметки) для внешних структур;
- подготовка продуктовых решений, включая описание userstory, прототипирования интерфейсов...
- формирование схем, включая bpmn, sequence;
- таск трекер с возможностью интеграции с гитом.

Atlassian не предлагать!

Буду очень признательна за предложения!!!
Тогда можно подумать про docs as code, взять любой подходящий генератор из списка: https://www.staticgen.com/. Но есть тонкости:
— выгрузку в PDF придётся подопиливать руками
— хороших инструментов для описания интерфейсов текстом пока нет. Есть ImagineUI, который пишет @vadkou
— не всем участникам будет сразу в кайф писать plain text и пользоваться гитом. Особенно тем, кто далёк от разработки.
источник

NV

Nick Volynkin in DocOps-сообщество
@eslysenko а что именно вы хотите с гитом интегрировать?
источник

NV

Nick Volynkin in DocOps-сообщество
Даже так спрошу: расскажите, как вы видите жизненный цикл документа в вашей системе. Где будет появляться задача, где редактировать, где рецензировать, как выпускать/публиковать?
источник

EL

Ekaterina Lysenko in DocOps-сообщество
Nick Volynkin
Тогда можно подумать про docs as code, взять любой подходящий генератор из списка: https://www.staticgen.com/. Но есть тонкости:
— выгрузку в PDF придётся подопиливать руками
— хороших инструментов для описания интерфейсов текстом пока нет. Есть ImagineUI, который пишет @vadkou
— не всем участникам будет сразу в кайф писать plain text и пользоваться гитом. Особенно тем, кто далёк от разработки.
Думали уже над этим, не сходимся по задачам, это явно не единое решение, тем более для рисования схем и описания продукта не очень ;(
источник

EL

Ekaterina Lysenko in DocOps-сообщество
Nick Volynkin
@eslysenko а что именно вы хотите с гитом интегрировать?
Тасктрекер
источник

NV

Nick Volynkin in DocOps-сообщество
а в гите будет что?
источник

EL

Ekaterina Lysenko in DocOps-сообщество
Nick Volynkin
а в гите будет что?
Код, гит я бы в связке с тасктрекером хотела видеть, чтобы pr удобно было смотреть, как минимум.
источник

NV

Nick Volynkin in DocOps-сообщество
это будет код продукта, который вы документируете, или код самой документации?
источник

NV

Nick Volynkin in DocOps-сообщество
Telegram
DocOps / Docs as code
Документация для SRE
#seeking_sre #sre

В сентябре 2018 года вышла книга Seeking SRE от издательства O'Reily. В ней есть целая глава про документацию команды SRE.
Буду понемногу конспектировать-переводить эту главу. Вот первая часть.

Часть 1/21. Качество документации
Как определить качество командной документации? Есть два аспекта качества:

1. Структурное качество. Документация выглядит так, как должна:
   — Текст без орфографических ошибок.
   — Сответствует гайдлайнам по стилю.
   — Использует правильный тон.
   — Хорошо организована, в ней легко ориентироваться.

2. Функциональное качество. Хорошая документация решает задачу, для которой написана.
Например, для оценки качества плейбука (playbook, runbook) стоит задать такие вопросы:
   — Покрывает ли 100% возможных алертов (alerts, чрезвычайных ситуаций)?
   — Может ли команда полагаться на этот плейбук для решения своих задач?
   — Насколько плейбук «highly available».
     Если дока по починке k8s лежит в wiki, которая хостится в этом же k8s, то…
источник

C

Constantine in DocOps-сообщество
Nick Volynkin
это будет код продукта, который вы документируете, или код самой документации?
перевод книги по sre будет?
источник

NV

Nick Volynkin in DocOps-сообщество
Constantine
перевод книги по sre будет?
я вот думаю, не влепит ли мне издательство иск за этот небольшой конспект )))
источник

NV

Nick Volynkin in DocOps-сообщество
Перевод будет, если будет контракт с издательством. ))
источник

C

Constantine in DocOps-сообщество
Nick Volynkin
я вот думаю, не влепит ли мне издательство иск за этот небольшой конспект )))
так ее ж можно читать бесплатно https://landing.google.com/sre/book/index.html
источник

NV

Nick Volynkin in DocOps-сообщество
Constantine
так ее ж можно читать бесплатно https://landing.google.com/sre/book/index.html
это вроде SRE Book, а тут другая книга, Seeking SRE
источник

C

Constantine in DocOps-сообщество
о_О не слышал про такую
источник

NV

Nick Volynkin in DocOps-сообщество
ну так она вышла в сентябре вот только, два месяца как
источник