CodiLime Tech Talk - Jarek Łukow: You need a cloud to test a cloud: using Ope...
CodiLime Tech Talk - Michał Sochoń: Sphinx, reST & Ansible
1. Sphinx, reST i Ansible
Wprowadzenie do automatycznego generowania dokumentacji
2. Info
● Na SlideShare dostępne są notatki
pod oknem prezentacji w zakładce Notes
● Prezentacja na SlideShare zawiera więcej
slajdów niż materiał wideo.
3. Agenda
● O czym jest ta prezentacja
● O czym NIE jest ta prezentacja
● Problemy i Skutki
● Jak można to naprawić
● Co dostajemy w efekcie
● Przykład z Ansible
4. O czym jest ta prezentacja
● Jaki jest ogólny problem?
● Jakim sposobem możemy to rozwiązać
● Co dostaniemy w zamian
● W jakim kierunku można to pociągnąć
5. O czym NIE jest ta prezentacja
● Jaki pisać dobrą dokumentację
● Przegląd innych rozwiązań
● Niestety nie mam komend dla Windows
● reStructuredText specjalnie zdawkowo opisany
6. Problem
● Nie chce mi się
● Brak czasu
● Permanentna zmiana
● Nie wiemy jak
7. Skutki
● O tamten w rogu wie...
● Chcą dokumentację teraz?
● Mam kogoś szkolić?
● Fajnie, że mamy internet
● FFFFFFFFFFF…..
21. reStructuredText
● Język do tworzenia dokumentacji
● Oparty na znacznikach
● Bardzo łatwo przejść z MarkDown na reST
● Można konwertować .md na .rst
● Złożone projekty pokazują jego wyższość nad .md
● Krótki wstęp
Slajd: 2
Wyjaśnienie, gdzie są notatki na slideShare
Slajd: 3
Slajd: 4
Slajd: 5
reStrucuredText (reST) specjalnie zdawkowo opisany, bo Sphinx moze konwertować dokumentacje z innych formatów.Markdown jest dobry do prostych opisów, ale po jakimś czasie większość ludzi przechodzi na reST jeśli znają oba systemy, a nie mają potrzeby przechodzenia na inne rozwiązania.
Slajd: 6
- zrobię to potem
- to jest samo dokumentujący się kod!
- nie lubimy się powtarzać, ciągły pożar na fejsbuku/jirze :)
- ten dokument na wiki jest przestarzały, robimy to teraz inaczej…
- nie mamy czasu aby przemyśleć dokumentację bo są ważniejsze rzeczy
- nie znamy innych narzędzi czy metod, markdown starczy...
Slajd: 7
- wiedza plemienna bo nie ma czasu pisać, albo co gorsza, ludzie chronią stanowiska
- wszyscy wszystko rzucają i robią dokumentację
- mamy tyle roboty i taki chaos, że realnie co najmniej 2 osoby są poza robotą - wdrażający i wdrażany
- dostań się do dokumentacji online jak odciąłeś internet / wyłączyłem serwer w dokumentacją / klatka Faraday'a
- jest awaria, ja się nie znam, telefon do przyjaciela w nocy, który jest na urlopie….
Slajd: 8
Duuuhhh guess what.
Slajd: 9
Cpt Obvios for the rescue. Tłum szaleje, wyrywa kaloryfery ze ścian.
Slajd: 10
- write once, die whenever
- rozproszenie wiedzy
- inkludowanie komentarzy zamiast grzebanie w kodzie,a tym bardziej unikamy kopiowania
- podzielenie całości na mniejsze, przyswajalne kawałki
- zachowanie aktualnej dokumentacji
- różne formaty i dostępność online/offline
- co innego potrzebuje startujący w pracy a co innego osoba na on-callu
- integracje z innymi narzędziami i serwisami, projektami, można się skupić tylko na specyficznych aspektach, a odesłać do dokładniejszej dokumentacji gdzie indziej
Slajd: 11
- zrobić listę tego co mamy i w jakiej formie, szybko ogólnie określić czy cos sie nadaje czy wymaga poprawy
- można wersjonować per release
- automatyczne generowanie dokumentacji - jenkins/travis itd i automatyczna publikacja np na www, internal wiki, mailem...
- wiercenie w brzuchu albo wysłanie kogoś na dyżur, w sumie dokumentacja powinna być użyteczna dla nas samych
Slajd: 12
- pewnie już część tego mamy, w różnej formie - odkurzyć stare papiery
- Masa ciekawostek zaszyta w komentarzach, szczególnie jak ukryte gdzieś na dole.
- Wiedza plemienna, mniejsze kawałki łatwiej spisać, każdy może dopisać to co mu sie przypomni
- Inne źródła - czat, jira, RCA, pentagramy na white-boardach ;)
Slajd: 13
Dlaczego sphinx?
- pewnie juz masz pythona
- w tytule prezentacji jest Ansible, więc mamy pythona
- potrafi generować dokumentację z innych języków, z docstrings
- stabilny na tyle że wiele projektow go używa, np kernel org na niego przeszedł w 2016r
Slajd: 14
Instalacja na start jak na ubuntu, w innych systemach podobnie.
Najnowsze wersje z pip, można użyć virtualenv, pipenv.
Na szaro to prefixy dodatkowych wartościowych paczek
A gdzie docker?
Sam se znajdz ;)
Slajd: 15
Quickstart zawiera kilka ważnych pytań i uwaga na domyślne odpowiedzi
Domyślnym formatem dokumentacji jest .rst, czyli reStructuredText, ale moze byc .md czyli Markdown
Uwaga na istniejący plik makefile
Config.py - prędzej czy pózniej tam popatrzycie
Slajd: 16
Można wstawić kod pythona, przydaje się przy bardziej zaawansowanych dodatkach.
Slajd: 17
Uwaga na identacje w reST, o tym za chwilę.
Plik example.rst dodajemy do indeksu, i wrzucamy do sources/example.rst z kawałkami jakiegoś reST’a
Slajd: 18
Budujemy, można wpisać komendy sphix-doc jak nie chcemy Makefile.
Make clean
Make html
Samo wpisanie make pokaże dodatkowe opcje
Slajd: 19
Domyślna skórka szału nie robi
Slajd: 20
Entuzjazm po make html nie wszystkim się udziela… ;)
Slajd: 21
Dobra, co jest w plikach .rst?
Slajd: 22
Przykład, z tego wygenerujemy kod.
Niestety listy i obrazka niet.
Slajd: 23
Przykład renderowania do html
Pygments do podświetlania innych języków, tutaj json.
Slajd: 24
Makefile kryje kilka komend specyficznych dla sphinxa
Można zmiksować z własnymi targetami w makefile
Slajd: 25
Linkcheck sprawdza czy url są osiągalne, można w confie podać jakie wzorce nie są sprawdzane
Changes pokazuje zmiany w dokumentacji
Doctest i Coverage - czy nasze docki mają sens i pokrywają się kodem. W ansible w czystym yamlu bezużyteczne, ale jak masz już pythona (albo np zamiast ansible używasz fabrica) to się przydaje.
Slajd: 26
Przykład linkcheck, przydaje się w wykrywaniu jak jakis inny projekt zmienia swoja stronę..
Slajd: 27
Inne formaty wymagają dodatków na systemie, np latexa
Slajd: 28
Default skin, troche straszny ;)
Można zmieniać logo inne elementy aby bardziej spersonalizować dokumentacje
Slajd: 29
RTD (read the docs) jest to jeden z popularniejszych theme
Slajd: 30
Guzzle - jak ktos siedzial nad AWS Boto3 to pewnie poznaje
Slajd: 31
Twitter
Slajd: 32
Sugeruje zaznajomić się z nimi, oczywiście wiele się powtarza
Uwaga na te same paczki opublikowane z inną nazwa...
Slajd: 33
Autodoc / napoeon / numpy / google comment standards
Git dla prostych projektów, releases jak mamy srs bsns.
Versioning jak chcemy budować wiele wersji dokumentacji na raz.
Robot framework deprecated afair, przeszli na docstrings.
Slajd: 34
Extlinks - np jira, bitbucket or whatever
Intersphinx, jak miksujemy innymi projektami
Viewcode jak dajemy linka wprost do repo kodu
Issue tracker - jira, mantis, trac i takie tam.
Slajd: 35
Graphviz wymaga paczki, podobnie aafigure.
Generacja .dot do obrazka albo svg
Slajd: 36
Uwaga na output, można sobie zrobić niechcący krzywdę
Slajd: 37
Jak ktoś wymaga bardzo dziwnych rzeczy.
Hieroglyph - html5 presentation framework
Tut - do robienia tutoriali
Autobuild aby nie wpisywać make co chwile
Slajd: 38
Do publikowania:
Sphinx-me - read the docs official page
Confluence, działa z Atlassian Confluence, w tym także wersja Cloud. Niestety trzeba samemu pokombinować bo Confluence jest specyficzny.
Slajd: 39
Dobra, a jak tu wsadzić ansible?
Slajd: 40
Zakładamy, że interesują nas na razie playbooki.
Poprzez parsowanie komentarzy zamieszczonych w yml, pod warunkiem, że mają początkowy i końcowy znacznik, domyślnie ###
Slajd: 41
Dorzucamy do projektu pakiety pip
Dorzucamy do configa sekcje, gdzie sa pliki yaml, dorzucamy skórkę.
Slajd: 42
Edycja naszego głównego playbooka
Domyślnie sekcja zaczynająca komentarz zaczyna się i kończy trzema znakami #
Wiele sekcji jest łączonych w jeden dokument.
Inne dodatkowe znaki są dodawane na pałę, jak nie ma znacznika to komentarz jest ignorowany i nie będzie w dokumentacji.
Slajd: 43
Dorzucamy etcd.rst do listy, na dole, bez rozszerzenia.
Slajd: 44
A plik etcd.rst zawiera takie bebechy, uwaga na autoyaml i ścieżkę
Make clean html
I mamy output widoczny na prawo.
Slajd: 45
Dorzucamy kawałki kodu w reST, warning box i listę parametrów jakimi można karmić playbook/role, tak pokrótce.
Środkowej części nie ma aby sie zmiescilo na slajdzie.
Slajd: 46
Efekt wyjściowy zmian w dokumentacji.Żółty warning box, lista Parameters.
Slajd: 47
Slajd głównie dla deweloperów.
Pythonowe docstringi - numpy/google docstring guide = zobacz dodatek napoleon.
Ansible ma swój guideline jak pisać dokumentację do modułów - jest strasznie długi i niestety nie mamy na to czasu.
Wychodzę z zalozenia, ze jak piszesz moduły do ansible to tak czy siak przekopałeś się przez dokumentację Ansible.
Slajd: 48
Konwersja markdown moze byc problemem, lepiej pewne rzeczy zlinkowac ręcznie.
Inaczej powstaje chaos i zniszczenie, bo każdy Markdown może mieć własny styl pisania.
Slajd: 49
Ansible-playbook-graph
Ansigenome
Generują svg - można więc wykonać je przed dokumentacja, wrzucić do wybranego katalogu a następnie osadzić .svg w dokumentacji.
Będą więc automatycznie aktualizowane per aktualizacja playbooka i build w jenkinsie.
Slajd: 50
Matplotlib idealnym przykładem jak można używać sphinxa, Blender pokazuje jak mozna dostosowac css i pygments (kolorowanie składki względem języka).
Doc8 - inspirowany pip8, do weryfikowania dokumentów np czy jet zgodny z reST, czy ma odpowiednia dlugosc linii itd.
Sukcesywne rozszerzanie pipeline o doc build + publish.
Write the docs / Ops Record Card - jak pisać sensowna dokumentacje dla ludzi/siebie/operations.
Można się pokusić o jakieś czary jak openstack reno jeśli mamy problemy z faktu, że jesteśmy tak wielcy jak openstack ;)
Slajd: 51
- Czy trzeba używać makefile? Nie, w makefile sa komendy aby wykonywać program sphinx-doc, więc możemy np używać sphinx-doc bespośrednio.
- Czy można podać kilka formatów default? Nie wiem, chyba nie, lepiej raczej skonwertowac dokumenty na wybrany jeden format i nie mieszać. To raczej nie jest skomplikowany proces, chyba że mamy już dużo długich dokumentów.
- Czemu było tak krótko o reST/docstrings? Głównie dlatego, by nie uśpić publiczności. Chciałem pokazać rozwiązanie, które może być użyte przez wszystkich w zespole z fokusem na Opsów, którzy niekoniecznie tęsknią za kodowaniem ;) Jeśli kogoś to zainteresuje to na pewno pogrzebie sobie na spokojnie co w tym można więcej zrobić.
Slajd: 52
Czas na sucharka/dowcip:Słowa kluczowe jakie muszą paść na prezentacji:
Docker, klałd, klałd nejtif
Adżajl
Kontinjus Integrejszyn i deplojmęt
Maszin lernink i Big dejta
<aktualnie gorąca technologia>
:D