Wraz z coraz szybszym tempem dostarczania aplikacji wzrasta potrzeba zwiększenia niezależności zespołów developerskich. A co jeśli zepsuje się CI/CD albo wystąpi potrzeba otrzymania informacji o wydajności naszych rozwiązań? Podczas swojej prelekcji w ramach DevDuck meetupu Michał opowiedział o tym, o jakie elementy dziedziny DevOps możecie zadbać zarówno na początku projektu, jak i w trakcie jego trwania. Poruszył tematy standaryzacji tworzenia nowych repozytoriów, szablonów CI/CD, jak i infrastruktury. Było też trochę o bezpieczeństwie i o obserwowalności samych aplikacji. Na koniec opowiedział nam o możliwościach wczesnego planowania skalowalności oraz zabezpieczeniu aplikacji przed utknięciem u jednego dostawcy. Przygotujcie się na konkretne przykłady z jego doświadczenia. Więcej informacji znajdziecie na stronie: https://career.brainhub.eu/devduck/devops-meetup

2. Jak zostać Dev w DevOps?
Czyli o tym jak zwiększyć niezależność
zespołów developerskich
Michał Kaleta
DevOps Engineer
Gliwice, 27.06.2024

3. Agenda
1. Wrzuciłem sekret do repozytorium - Dlaczego Ja?
2. I znowu nie sformatowany kod, I znowu zmarnowany dzień
3. On-prem dla testów, chmura dla produkcji? - Trudne Sprawy
4. Co, jak i dlaczego robi moja aplikacja? - Ukryta Prawda
5. “Na moim komputerze działa” - Niesamowite Historie

4. 1 Nowe repozytorium, ale
co dalej?

5. Git hooks i inne bajery
● Formatter przed git commit
● Linter przed git push
● Conventional Commit Messages
● Git Leaks
Repozytorium

6. 2 Continuous integration,
delivery and deployment

7. Continuous integration
● CI wszędzie, zawsze, od samego początku
● Jeden stack? Jeden CI!
● Chyba że to JS - różne implementacje
● Czas trwania musi zadowalać zespół
● Pełny CI musi pokryć pełen zakres
CI

8. Continuous delivery,
czy może już deployment
● Deliver at least, deploy at most
● Czym częściej, tym lepiej …
● … chyba że nie działa …
● … no to rollback.
● Produkcja - automatycznie czy on-demand?
CD

9. 3 Skalowalne od początku

10. Czy skalować można
tylko w górę?
● Kontenery wszędzie i zawsze
● Multi-stage twoim przyjacielem na produkcji
● Gdy możliwe → rootless
● Najlepiej → distroless
● Zabezpieczenie na przyszłość ✓
● Brak vendor lock-in ✓
Konteneryzacja

11. 4 Bezpieczne od początku

12. Bezpieczeństwo jako
feature, nie wymaganie
● Bezpiecznie od początku
● Least Privilege Principle
● Dependabot i Renovate
● Zainstalujmy kolejną zależność, co złego może się
wydarzyć (xz backdoor)
Security

13. Monitoring
5

14. OODA
● Troche developersko, bardziej biznesowo
● Dobre dane, to zazwyczaj dobre decyzje
● Brak danych, to zawsze złe decyzje
● Od czego zacząć?
“A delayed game is eventually good, but a rushed game is
forever bad” ~ Shigeru Miyamoto
OODA

15. Monitoring i Analityka
● Performance a User Experience
● Analizujmy co dobrze działa
● Monitorujmy jak dobrze działa
● Statystyki platformy vs. aplikacji
Analityka

16. 6 Wiedza plemienna,
a może jednak ogólna?

17. Zepsuć, naprawić, zapomnieć
● Dokumentacja nie musi być uciążliwym obowiązkiem
● Zepsułeś? Zapytaj czy ktoś widział taki problem
● Naprawiłeś? Zostaw komentarz
● Zapomniałeś? Sprawdź dokumentację
Wiedza plemienna

18. Podsumowanie
1. Standardowe ustawienia repozytorium
2. CI wszędzie, CD gdzie się tylko da
3. Konteneryzacja jako wspólny format dostarczania softu
4. OODA → analityka i monitoring → OODA
5. Dzielenie się wiedzą, nie tylko na spotkaniach, ale zawsze

19. Thank you!
Questions?

20. 7 Extras

21. A co dalej?
● Infrastructure as Code
● Cloud - nieważne który
● Semantic Versioning
Extras