Size: a a a

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

2018 November 28

I

Igor in DocOps-сообщество
Ну если lein стоит в системе
что обычно подразумевается
источник

НН

Нац Нац in DocOps-сообщество
Неблагодарное дело - подразумевать
источник

I

Igor in DocOps-сообщество
Ну не скажите. Никто же не пишет что надо поставить гит, когда первая строка в документации git clone
источник

НН

Нац Нац in DocOps-сообщество
Igor
Ну не скажите. Никто же не пишет что надо поставить гит, когда первая строка в документации git clone
А Когда сам гит Ставишь
источник

I

Igor in DocOps-сообщество
Пример выше не про это
источник

СФ

Семён Факторович in DocOps-сообщество
напиши автору, предложи пофиксать документацию:)
источник

СФ

Семён Факторович in DocOps-сообщество
мы как раз с ним на прошлой конфе обсуждали, чтобы он поконтрибьютил в наш будущий сайт
источник

СФ

Семён Факторович in DocOps-сообщество
он нам услуги по сайтостроению, а мы ему — помощь с документацией
источник
2018 November 29

LZ

Lev Zabudko in DocOps-сообщество
Спасибо за статью! Достаточно понятная и хорошо структурирована документация во второй части. Разослал пост в наш сервис, мы как раз на пути к SRE. DevOps есть, но нужно строить круглосуточную поддержку
источник

LZ

Lev Zabudko in DocOps-сообщество
​​Почему важна SRE-документация
#seeking_sre #sre

Недавно писал про главу о документации из книги Seeking SRE. Вот вам ещё одна статья по той же теме: Why SRE Documents Matter. Там целая история про джуна-SRE по имени Zoë (Зоуи). На основе этой истории автор приводит примеры и объясняет смысл. Люблю этот жанр учебной литературы: в нём написана Цель, Дедлайн и Проект Феникс.

Max Rokatansky из Отуса перевёл эту статью на русский язык:

— часть 1: введение в SRE и зачем там документация,

— часть 2: конретные виды документации, в чём их польза, как их писать.

Статей про документацию на Хабре маловато, хочу чтобы их было больше. Давайте мотивировать авторов. Вот например, вторая часть про доки SRE только вчера опубликована, ещё можно ставить плюсы. 😉
источник

NV

Nick Volynkin in DocOps-сообщество
Lev Zabudko
Спасибо за статью! Достаточно понятная и хорошо структурирована документация во второй части. Разослал пост в наш сервис, мы как раз на пути к SRE. DevOps есть, но нужно строить круглосуточную поддержку
Рад, что вам пригодилось! Я там ещё начал переводить главу из книжки, вот начало: t.me/docops/191
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, то…
источник

ML

Maksim Lapshin in DocOps-сообщество
Да, lein это кусок clojure
источник

ML

Maksim Lapshin in DocOps-сообщество
Мне пришла в голову такая идея: делать скриншоты и скринкасты на базе автоматических тестов.

Для того что бы сделать свежий скриншот, надо прокликать в нужных местах в нужном порядке и фактически это же делает тестировщик и автоматический тест.

Есть ли практика делать скриншоты на базе автотестов?
источник

I

Igor in DocOps-сообщество
В селениум можно делать скриншоты
источник

ML

Maksim Lapshin in DocOps-сообщество
Да и видео снять тоже будет задача решаемая
источник

ML

Maksim Lapshin in DocOps-сообщество
Вопрос в другом: доверять скриншоты документации автотестам - это хорошая идея?
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
Maksim Lapshin
Вопрос в другом: доверять скриншоты документации автотестам - это хорошая идея?
Смотря что от скриншотов хочется получить

Нарезка скринов с мобайла для App Store/Google Play работает хорошо

Ловить какие-нибудь всплывающие сообщения для справки – это в любом случае неприятно)
источник

NV

Nick Volynkin in DocOps-сообщество
Maksim Lapshin
Мне пришла в голову такая идея: делать скриншоты и скринкасты на базе автоматических тестов.

Для того что бы сделать свежий скриншот, надо прокликать в нужных местах в нужном порядке и фактически это же делает тестировщик и автоматический тест.

Есть ли практика делать скриншоты на базе автотестов?
Selenium умеет делать скриншоты с веба.
источник

NV

Nick Volynkin in DocOps-сообщество
Maksim Lapshin
Вопрос в другом: доверять скриншоты документации автотестам - это хорошая идея?
насколько я помню,  в 2GIS такое практиковали
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
Nick Volynkin
насколько я помню,  в 2GIS такое практиковали
https://habr.com/company/2gis/blog/246831/
(любимая их статья :)

Тут в комментах обсуждают, как можно в тестировании эту практику использовать
источник