2023-10-02 18:13:55 +02:00
|
|
|
{
|
|
|
|
"cells": [
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"<div class=\"alert alert-block alert-info\">\n",
|
|
|
|
"<h1> Systemy informatyczne analizy danych</h1>\n",
|
|
|
|
"<h2> 3. <i>Ciągła integracja i ciągła ewaluacja</i>[wykład]</h2> \n",
|
|
|
|
"<h3>Filip Graliński, Krzysztof Jassem (2023)</h3>\n",
|
|
|
|
"</div>"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"<div class=\"alert alert-block alert-success\">\n",
|
|
|
|
" \n",
|
|
|
|
"<h2>Ciągła integracja </h2> \n",
|
|
|
|
" \n",
|
|
|
|
"Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
|
|
|
|
"<ul>\n",
|
|
|
|
" <li> zmiany w kodzie są regularnie przesyłane do centralnego repozytorium, </li>\n",
|
|
|
|
" <li> po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy. </li>\n",
|
|
|
|
"</ul>\n",
|
|
|
|
"</div>"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"<div class=\"alert alert-info alert-success\">\n",
|
|
|
|
" \n",
|
|
|
|
"<h2>Główne przesłanki CI </h2> \n",
|
|
|
|
" \n",
|
|
|
|
"Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
|
|
|
|
"<ul>\n",
|
|
|
|
" <li> szybsze lokalizowanie błędów w kodzie, </li>\n",
|
|
|
|
" <li> ciągły wzrost jakości oporgramowania, </li>\n",
|
|
|
|
" <li> szybkie wydawanie nowych wersji. </li>\n",
|
|
|
|
"</ul>\n",
|
|
|
|
"</div>\n",
|
|
|
|
"\n",
|
|
|
|
" \n",
|
|
|
|
"\n"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"## Przebieg pracy w Ciągłej Integracji\n",
|
|
|
|
"1. **Take Integrated Code**\n",
|
|
|
|
" * Pobieram kod z repozytorium.\n",
|
|
|
|
" * Instaluję kopię na swojej stacji roboczej. \n",
|
|
|
|
" \n",
|
|
|
|
"2. **Do Your Part**\n",
|
|
|
|
" * Opracowuję nowy kod.\n",
|
|
|
|
" * Opracowuję nowe testy jednostkowe.\n",
|
|
|
|
" \n",
|
|
|
|
"3. **Build on your machine**\n",
|
|
|
|
"\n",
|
|
|
|
" * **Repeat** \n",
|
|
|
|
" * Kompiluję swój kod i buduję wersję wykonywalną,\n",
|
|
|
|
" * Przeprowadzam testy jednostkowe,\n",
|
|
|
|
" * **Until**\n",
|
|
|
|
" * Kod się skompilował poprawnie oraz\n",
|
|
|
|
" * Testy zakończyły się powodzeniem.\n",
|
|
|
|
" \n",
|
|
|
|
"4. **Integrate with Repository**\n",
|
|
|
|
"\n",
|
|
|
|
" * Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.\n",
|
|
|
|
" * Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.\n",
|
|
|
|
" * **Go back to: Take Integrated Code**\n",
|
|
|
|
" * Przypadek 2. Tetsy się powodzą\n",
|
|
|
|
" * **Continue**\n",
|
|
|
|
" \n",
|
|
|
|
"5. **End Session**\n",
|
|
|
|
" * Gdy powiodły się wszystkie testy, mogę zakończyć sesję."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"## Dobre praktyki Ciągłej Integracji\n",
|
|
|
|
"(wg https://www.martinfowler.com/articles/continuousIntegration.html)"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Maintain a Single Source Repository\n",
|
|
|
|
" * Załóż mainline (linię główną): \n",
|
|
|
|
" * Deweloperzy powinni większość pracy składać na mainline.\n",
|
|
|
|
" * Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:\n",
|
|
|
|
" * naprawy błędów,\n",
|
|
|
|
" * tymczasowych eksperymentów,\n",
|
|
|
|
" * oznaczania wersji publikowalnych.\n"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Automate the Build\n",
|
|
|
|
" * Wersja wykonywalna powinna być tworzona jednym poleceniem.\n",
|
|
|
|
" * Dotyczy to zarówno repozytorium centralnego, jak i maszyn lokalnych."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Test Yourself\n",
|
|
|
|
" * Pisz testy jednostkowe.\n",
|
|
|
|
" * Uruchamiaj testy po każdej kompilacji."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Everyone Commits Everyday\n",
|
|
|
|
" * Każdy powinien \"codziennie\" wypychać swój kod do linii głównej.\n",
|
|
|
|
" * Umożliwia to wczesne wykrywanie konfliktów, gdyż...\n",
|
|
|
|
" * Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.\n",
|
|
|
|
" * Postulat wymaga rozbicia projektu na małe kawałki."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Every Commit Should Build the Mainline\n",
|
|
|
|
" * Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.\n",
|
|
|
|
" * Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins)."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Fix the Broken Builds Immediately\n",
|
|
|
|
"Co zrobić, jeśli jednak kod na \"mainline\" się nie buduje? \n",
|
|
|
|
"Znalezienie i poprawienie blędu jest priorytetem, ale:\n",
|
|
|
|
" * Nie debugguj kodu na centralnym repozytorium. \n",
|
|
|
|
" * Przywróć wersję wykonywalną na \"mainline\".\n",
|
|
|
|
" * Debugguj kod na maszynie lokalnej."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Make it Easy to Run the Latest Executable\n",
|
|
|
|
"* Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.\n",
|
|
|
|
"* Jest to niezbędne do:\n",
|
|
|
|
" * testowania integracyjnego (tester),\n",
|
|
|
|
" * rozmów z klientem (zarząd lub sprzedawca),\n",
|
|
|
|
" * prowadzenia projektu (kierownik zespołu).\n",
|
|
|
|
"* W specjalnej lokalizacji przetrzymuj wersje stabilne - \"do pokazania\"."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Keep the Build Fast\n",
|
|
|
|
"\n",
|
|
|
|
" * Maximum 10 minut na build + testy.\n",
|
|
|
|
" * A jeśli testy trwają dłużej?\n",
|
|
|
|
" * Testy dwuetapowe:\n",
|
|
|
|
" * kompilacja + testy jednostkowe przy każdym commicie,\n",
|
|
|
|
" * testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów)."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Clone the Environment\n",
|
|
|
|
" * Przygotuj klon środowiska produkcyjnego:\n",
|
|
|
|
" * ta sama wersja systemu operacyjnego\n",
|
|
|
|
" * ta sama baza danych\n",
|
|
|
|
" * te same biblioteki (nawet jak ich nie potrzebujesz) \n",
|
|
|
|
" * Wszystkie testy przeprowadzaj na przygotowanym środowisku."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Everyone Can See What's Happening\n",
|
|
|
|
"System powinien informować użytkowników o swoim statusie."
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"### Automate Deployment\n",
|
|
|
|
" * Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.\n",
|
|
|
|
" * Pozwala to na szybką reakcję, gdy \"coś się dzieje\". "
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"## Narzędzia Ciągłej Integracji\n",
|
|
|
|
"\n",
|
|
|
|
"https://www.katalon.com/resources-center/blog/ci-cd-tools/\n",
|
|
|
|
"\n",
|
|
|
|
"1. Jenkins\n",
|
|
|
|
"2. Circle CI\n",
|
|
|
|
"3. Team City\n",
|
|
|
|
"4. Bamboo\n",
|
|
|
|
"5. GitLab"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"## Korzyści z Ciągłej Integracji\n",
|
|
|
|
" * Minimalizacja ryzyka\n",
|
|
|
|
" * Łatwiejsze szacowanie terminu zakończenia prac\n",
|
|
|
|
" * Szybsza lokalizacja i naprawa błędów\n",
|
|
|
|
" * Świadomość stanu prac u całego zespołu\n",
|
|
|
|
" * Możliwość kontynuowania prac w przypadku odejścia dewelopera\n",
|
|
|
|
" * Możliwość pracy w środowisku rozproszonym\n",
|
|
|
|
" * Możliwość usunięcia bariery między wykonawcą i klientem"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"cell_type": "markdown",
|
|
|
|
"metadata": {},
|
|
|
|
"source": [
|
|
|
|
"## Przykład - Jenkins\n",
|
|
|
|
"\n",
|
|
|
|
"https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n",
|
|
|
|
"\n"
|
|
|
|
]
|
|
|
|
}
|
|
|
|
],
|
|
|
|
"metadata": {
|
|
|
|
"author": "Krzysztof Jassem",
|
|
|
|
"email": "jassem@amu.edu.pl",
|
|
|
|
"kernelspec": {
|
2023-11-05 16:35:59 +01:00
|
|
|
"display_name": "Python 3 (ipykernel)",
|
2023-10-02 18:13:55 +02:00
|
|
|
"language": "python",
|
|
|
|
"name": "python3"
|
|
|
|
},
|
|
|
|
"lang": "pl",
|
|
|
|
"language_info": {
|
|
|
|
"codemirror_mode": {
|
|
|
|
"name": "ipython",
|
|
|
|
"version": 3
|
|
|
|
},
|
|
|
|
"file_extension": ".py",
|
|
|
|
"mimetype": "text/x-python",
|
|
|
|
"name": "python",
|
|
|
|
"nbconvert_exporter": "python",
|
|
|
|
"pygments_lexer": "ipython3",
|
2023-11-05 16:35:59 +01:00
|
|
|
"version": "3.9.13"
|
2023-10-02 18:13:55 +02:00
|
|
|
},
|
|
|
|
"subtitle": "06. Prototypowanie i ciągła integracja[wykład]",
|
|
|
|
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
|
|
|
"year": "2021"
|
|
|
|
},
|
|
|
|
"nbformat": 4,
|
|
|
|
"nbformat_minor": 4
|
|
|
|
}
|