Inleiding DevOps, Versiebeheer en Git(Hub)

Wat is DevOps?¶

De naam van deze module is DevOps Basic for Developers. Maar wat is "DevOps" eigenlijk?

Geschiedenis¶

De term DevOps is in 2009 bedacht door Patrick Debois als naam voor de eerste devopsdays conferentie (in Gent!)

In diezelfde periode zien we de opkomst en popularisering van Agile met een zekere overlap in normen en waarden.

Sinds 2009 is de term DevOps behoorlijk afgedreven van zijn oorsprong. In plaats van de oorspronkelijke culturele/filosofische beweging verwijst DevOps tegenwoordig vooral naar een set praktijken en tooling om software snel en betrouwbaar te bouwen, testen, deployen en beheren.

In de praktijk bedoelen mensen met "DevOps" meestal een combinatie van:

• CI/CD-pipelines (geautomatiseerd bouwen, testen en deployen)
• Infrastructure as Code (Terraform, CloudFormation, Ansible, Pulumi) voor het beheren van cloud-infrastructuur (AWS, Azure, GCP)
• Containerization en Orchestration (Docker, Kubernetes)
• Monitoring, Logging en Observability (Prometheus, Grafana, de ELK-stack, Datadog)
• Automatisering van alles wat repetitief is in de delivery-pipeline

Zo is er in de industrie zelfs een nieuwe rol of functietitel ontstaan: de "DevOps Engineer". Ironisch genoeg is dit in zekere zin precies wat de oorspronkelijke DevOps-beweging probeerde te vermijden — de bedoeling was juist om de muur tussen developers en operations te laten verdwijnen, niet om er een nieuwe specialist bij die muur neer te zetten. Maar de markt ging de andere kant op. Een DevOps engineer is tegenwoordig doorgaans:

• Een gespecialiseerde infrastructuur-/operations-engineer die CI/CD-pipelines bouwt en onderhoudt
• Verantwoordelijk voor het provisionen van cloud-infrastructuur en IaC
• Beheert containers/orchestration-platformen
• Zet monitoring-, alerting- en incident response-tooling op
• Schrijft automatiseringsscripts (Python, Bash, Go) om systemen aan elkaar te knopen
• Vaak de brug tussen software engineers en traditioneel sysadmin-/infrawerk

In feite is het een meer automatiseringsgerichte evolutie geworden van de oude "sysadmin"- of "release engineer"-rol, met een sterke focus op cloud-native tooling.

Versiebeheer en Git¶

Inleiding¶

DevOps en versiebeheer zijn onlosmakelijk met elkaar verbonden. De kern van DevOps is sneller en betrouwbaarder software opleveren door automatisering en samenwerking — en beide vertrekken vanuit versiebeheer. Versiebeheer is het fundament waarop alle DevOps-praktijken uit de rest van deze module bouwen.

We leren werken met Git, het populairste versiebeheersysteem dat aan de basis ligt van online platformen als GitHub.

In principe kan je alle voorbeelden uit de lessen zelf uitvoeren. Het is zeker een goed idee om dit te doen en zelf verder te experimenteren met de verschillende commando's.

Weersta de verleiding om de exacte commando's en instructies te copy-pasten of ze door een AI Agent te laten uitvoeren. Door zelf de commando's in te tikken zet je al een eerste stap naar het onthouden en toepassen van de materie.

Misschien vraag je je af waarom Git wordt aangeleerd, en niet een van de (vele) andere systemen. In een Stack Overflow developer survey uit 2023 blijkt dat bijna 94% van de bevraagde ontwikkelaars Git gebruikt.

Als je vandaag aan de slag wil in de softwareindustrie, of gewoon als hobbyist, is kennis van Git een absolute must. Git is:

• Populair
• Snel en efficiënt
• Erg geschikt voor samenwerking
• Open Source
• De-facto de standaard bij gebruik van AI

Versiebeheer, Wat en Waarom¶

Versiebeheer (of version control) is een essentieel hulpmiddel bij softwareontwikkeling. Het maakt het mogelijk om wijzigingen in de broncode systematisch bij te houden, eerdere versies terug te halen, en samen te werken zonder dat werk verloren gaat of overschreven wordt. Voor individuele ontwikkelaars betekent dit veiligheid en overzicht, voor teams betekent het efficiëntere samenwerking, duidelijke verantwoordelijkheid en minder kans op fouten.

De oorsprong van versiebeheer ligt in de jaren '70 en '80, toen de eerste generatie programmeerteams behoefte kregen aan methodes om broncode te organiseren. Vroege systemen waren vaak lokaal en bestonden uit eenvoudige bestandsarchieven, zoals SCCS (Source Code Control System, 1972) en RCS (Revision Control System, 1982). In de jaren '90 en 2000 kwamen meer geavanceerde systemen zoals CVS en later Subversion (SVN), die beter geschikt waren voor samenwerking binnen teams.

Versiebeheer is van algemeen nut, tot ver buiten het domein van softwareontwikkeling zelf. Denk bijvoorbeeld aan hoe (vroeger) vaak samengewerkt werd aan documenten of spreadsheets, door deze via email of fileservers uit te wisselen. Er werd dan automatisch aan ad-hoc-versiebeheer gedaan om bvb. een versienummer in de bestandsnaam te plaatsen. Iedereen die ooit documenten als Project Plan v41_3 Final Version_2.docx heeft gezien weet hoe chaotisch dit is.

Vergelijk met wat we vandaag als vanzelfsprekend vinden in applicaties als Google Docs.

Ook bij softwareontwikkeling werden vroeger vaak zogenaamde patches naar elkaar gemaild om aanpassingen voor te stellen.

From: junior@bigcorp.com
To: senior@bigcorp.com
Subject: please review

--- demos/flask/hello.py        2025-08-23 11:51:01
+++ demos/flask/hello_who.py    2025-08-24 08:49:30
@@ -3,6 +3,6 @@
 app = Flask(__name__)


-@app.route("/hello")
-def hello():
-    return "Hello!"
+@app.route("/hello/<name>")
+def hello(name):
+    return f"Hello {name}!"

Een modern versiebeheersysteem biedt tal van voordelen, o.a.

• Een volledige en exacte geschiedenis van alle aanpassingen (wie, wat, wanneer, en waarom)
• Je kan verschillende parallelle versies beheren van één programma of codebase
• Maakt aanpassingen door verschillende ontwikkelaars (en/of AI-assistenten!) mogelijk en werkbaar - in parallel!

Versiebeheer en AI¶

AI-assistenten (of agents) zoals Copilot, Codex en Claude zijn vandaag uitgegroeid tot vaste tools in de softwareontwikkeling. Ze genereren razendsnel code — maar jij blijft verantwoordelijk voor alles wat in je project terechtkomt. Juist daarbij is versiebeheer onmisbaar:

• Controle vooraf: met een diff bekijk je exact wat een AI-tool heeft aangepast voor je het aanvaardt.
• Vangnet: werkt een voorstel niet, dan keer je eenvoudig terug naar de laatste werkende versie.
• Overzicht: kleine, frequente aanpassingen laten toe om achteraf precies na te gaan wanneer — en door wie (of wat!) — een wijziging werd doorgevoerd.
• Ruimte om te experimenteren: op een aparte branch probeer je AI-voorstellen uit zonder je werkende code in gevaar te brengen.
• Parallelle uitvoering: met worktrees kan je tegelijk meerdere agents aan verschillende taken laten werken binnen een codebase.

De integratie werkt ook in de andere richting: de meeste AI-tools werken rechtstreeks met Git en GitHub. Ze gebruiken je code en geschiedenis als context, stellen aanpassingen en pull requests voor, of bespreken wijzigingen in een review.

Git Geschiedenis¶

Tot 2005 gebruikten de ontwikkelaars van de Linux kernel een commercieel versiebeheersysteem genaamd BitKeeper. In dat jaar verzuurde de relatie tussen het ontwikkelingsteam en het bedrijf achter BitKeeper. Dit heeft hen gemotiveerd om een eigen, open-source versiebeheersysteem te schrijven. Git was geboren.

De mythe vertelt dat een gefrustreerd Linus Torvalds de eerste rudimentaire versie van Git in 5 dagen heeft geschreven.

De doelstellingen bij de ontwikkeling waren:

• Snelheid
• Eenvoudig design
• Diepe ondersteuning voor non-lineaire ontwikkeling met duizenden ontwikkelingsstromen (zogenaamde branches)
• Volledig gedistribueerd
• Mogelijkheid om heel grote codebases efficiënt te beheren (de Linux kernel telde in 2005 ongeveer 6 miljoen lijnen code - vandaag zijn dat er meer dan 40 miljoen)

Over de betekenis van de naam Git kan je eindeloos discussiëren. In de README.md van de eerste commit van Git lezen we:

    GIT - the stupid content tracker

"git" can mean anything, depending on your mood.

 - random three-letter combination that is pronounceable, and not
   actually used by any common UNIX command.  The fact that it is a
   mispronounciation of "get" may or may not be relevant.
 - stupid. contemptible and despicable. simple. Take your pick from the
   dictionary of slang.
 - "global information tracker": you're in a good mood, and it actually
   works for you. Angels sing, and a light suddenly fills the room.
 - "goddamn idiotic truckload of sh*t": when it breaks

I'm an egotistical bastard, and I name all my projects after myself.
- Linus Torvalds

GitHub¶

Git is gedistribueerd. We gaan hier later dieper op in - maar wat we nu al kunnen afleiden is dat data (code) die we in Git bewaren op verschillende plaatsen beschikbaar kan zijn.

Git is hier erg flexibel in, maar typisch betekent dit dat code op een gemeenschappelijke server staat en individuele ontwikkelaars een lokale kopie hebben. Op regelmatige basis kan dan nieuwe code van de server worden opgehaald en doorgestuurd.

Alle code van één project noemen we in Git een repository (letterlijk opslagplaats). We gebruiken meestal de afkorting repo.

GitHub is ongetwijfeld de bekendste publieke Git server en wordt elke dag door miljoenen ontwikkelaars gebruikt.

GitHub Account¶

Als je nog geen account hebt op GitHub klik dan rechtsboven op Sign up en vul je gegevens in.

Met een gratis GitHub account kan je al heel wat doen. Het belangrijkste hierbij is dat je een onbeperkt aantal Git repos kan aanmaken!

Een eerste repo¶

Op verschillende plaatsen kan je een knop Create repository of Create project terugvinden - zeker als je net een nieuw account hebt gemaakt. Maar je kan altijd een nieuwe repo aanmaken via de knop bovenaan.

Op de volgende pagina moet je dan een aantal eigenschappen van de nieuwe repo kiezen:

• Owner: Je eigen account
• Repository name: Een vrij te kiezen naam (ASCII letters, cijfers, ., - en _) - bvb. syntra-git-les-1
• Visibility: Een Private repo is enkel toegankelijk voor ingelogde accounts die jij expliciet toevoegt. Het is handig als je voorlopig voor Public kiest zodat we elkaars repos kunnen bekijken.
• Add README: Vink dit aan zodat je kan starten met een repo die niet leeg is.

Een eerste 'commit'¶

Je nieuwe repo bevat één bestand: README.md. Via de knop kom je in een online editor terecht. Voeg een paar woorden toe in het bestand en klik dan op de Commit changes... knop.

Je kan dan een titel (Commit message) en optionele extra beschrijving (Extended description) invullen. Maak gebruik van die laatste zodat je het effect kan zien in de commit geschiedenis.

Je ziet nu de informatie over jouw commit. GitHub laat altijd de informatie over de laatste commit zien. Als je op klikt krijg je ook de extra beschrijving te zien.

Rechts op dezelfde lijn als de commit staat een icoon. Als je daar op klikt krijg je een lijst met alle commits. In dit geval slechts 2: de oorspronkelijke commit die GitHub automatisch heeft gemaakt (omdat we dit aangevinkt hadden) en onze eigen commit.

Als je op de titel van een commit klikt krijg je alle informatie over die specifieke commit. O.a. de volledige beschrijving, de ID van de voorgaande commit (parent) en alle aanpassingen (diff): nieuwe, verwijderde en gewijzigde lijnen.

In dit geval is slechts één bestand aangepast maar een enkele commit kan ook verschillende bestanden omvatten (en nieuwe bestanden toevoegen of oude verwijderen).

Intermezzo: Markdown¶

Tekst die je in je browser te zien krijgt (zoals deze cursus!) wordt geschreven in HTML. Dat is een zogenaamde opmaaktaal. Een (programmeer-)taal waarin de opmaak van de tekst verwerkt is. Wat is een hoofding (heading), welke woorden vetgedrukt zijn, links naar andere pagina's, enz.

HTML is eenvoudig te lezen en verwerken door een programma (zoals een browser dus).

Maar HTML is helemaal niet eenvoudig te lezen en verwerken door mensen.

Markdown is ook een opmaaktaal, met als doel zo leesbaar mogelijk te blijven voor mensen; maar toch nog verwerkbaar te zijn door een computerprogramma.

Hieronder zie je dezelfde tekst, uit het begin van deze pagina, in HTML en in Markdown. Het ligt voor de hand dat zowel het schrijven als het lezen van de tekst in Markdown een stuk aangenamer is.

<h1 id="les-1-inleiding-versiebeheer-en-git">Les 1 - Inleiding Versiebeheer en Git
<a class="headerlink" href="#les-1-inleiding-versiebeheer-en-git" title="Permanent link">&para;</a></h1>
<h2 id="wat-is-devops">Wat is DevOps?
<a class="headerlink" href="#wat-is-devops" title="Permanent link">&para;</a></h2>
<h3 id="geschiedenis">Geschiedenis<a class="headerlink" href="#geschiedenis" title="Permanent link">&para;</a></h3>
<p>
De term DevOps is in 2009 bedacht door
<a href="https://www.jedi.be">Patrick Debois</a>
als naam voor de eerste
<a href="https://devopsdays.org">devopsdays conferentie</a> (in
<a href="https://legacy.devopsdays.org/events/2009-ghent/program">Gent</a>!)
</p>
<p>
In diezelfde periode zien we de opkomst en
popularisering van
<a href="https://nl.wikipedia.org/wiki/Agile-softwareontwikkeling">
<em>Agile</em></a>
met een zeker overlap in normen en waarden.
</p>

# Les 1 - Inleiding Versiebeheer en Git
## Wat is DevOps?
### Geschiedenis

De term DevOps is in 2009 bedacht door
[Patrick Debois](https://www.jedi.be)
als naam voor de eerste
[devopsdays conferentie](https://devopsdays.org) (in
[Gent](https://legacy.devopsdays.org/events/2009-ghent/program)!)

In diezelfde periode zien we de opkomst en
popularisering van
[_Agile_](https://nl.wikipedia.org/wiki/Agile-softwareontwikkeling)
met een zeker overlap in normen en waarden.

Markdown is oorspronkelijk in 2004 ontwikkeld door John Gruber en Aaron Swartz. De oorspronkelijke specificatie is nog beschikbaar en nog steeds een goed startpunt.

Waarom Markdown?¶

Binnen deze opleiding, en zeker binnen de DevOps module, is een basiskennis van Markdown erg belangrijk...

• Documentatie die meegroeit met code: README-bestanden, wiki's en andere documenten worden meestal in Markdown geschreven omdat het snel te schrijven en te lezen is, zonder ingewikkelde editors nodig te hebben.
• Rechtstreekse ondersteuning op GitHub: GitHub (en gelijkaardige platformen) rendert Markdown automatisch in README's, issues, pull requests en commentaren. Een goede beheersing van Markdown zorgt ervoor dat je snel en duidelijk kan communiceren. GitHub heeft zelfs zijn eigen uitbreiding op Markdown: GitHub Flavored Markdown, of GFM!
• Versiebeheer-vriendelijk: Omdat Markdown gewone tekst is, werkt het perfect met Git. Je kunt wijzigingen makkelijk vergelijken, samenvoegen en reviewen, net als bij code.
• CI/CD en automatisering: Veel DevOps-tools (zoals documentatiegeneratoren of static site builders) gebruiken Markdown als taal om automatisch documentatie te bouwen en te publiceren.
• Gebruik bij AI-tools: Agents als Claude Code, Codex of OpenCode werken vaak met Markdown. Bijvoorbeeld voor het opstellen van skills of AGENTS.md/CLAUDE.md instructies.

Sinds 2004 is Markdown natuurlijk geëvolueerd - maar alle implementaties en varianten blijven vrijwel volledig compatibel met die oorspronkelijke specificatie.

Binnen het Python-ecosysteem wordt vooral python-markdown gebruikt. GitHub heeft zijn GFM die dan weer een uitbreiding is van CommonMark.

Markdown Basis¶

De Markdown in 60 seconds referentie op de CommonMark website is een heel duidelijk overzicht en een ideaal startpunt.

De belangrijkste aanvullingen van CommonMark en/of GFM zijn:

Code block met syntax-highlighting¶

https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks#syntax-highlighting

```python
def hello(name: str):
    print(f"Hello there {name}!")
```

def hello(name: str):
    print(f"Hello there {name}!")

Tabellen¶

https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables

| Boek                | Auteurs                               |
|---------------------|---------------------------------------|
| The DevOps Handbook | Gene Kim, Patrick Debois, John Willis |
| The Phoenix Project | Gene Kim, Kevin Behr, George Spafford |

Auto-link References¶

https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls

In Markdown documenten die je in GitHub bekijkt (zoals een `README.md`):

- Kan je linken naar een Issue of Pull request in de huidige repo: #123
- Of in een andere repo: fastapi/fastapi#16231
- Worden URLs automatisch een link: https://docs.github.com
- Worden commit IDs automatisch een link naar die commit: 8540565

Oefening¶

Pas het README.md bestand in je GitHub repo opnieuw aan en zorg dat het er als volgt uit komt te zien. De link op het einde moet naar deze website gaan: https://docs.python.org/3/library/stdtypes.html#string-methods.

Commit het aangepaste bestand als je klaar bent.

# Werken met Strings in Python

Een **string** is een reeks tekens die je gebruikt om tekst op te slaan, zoals `"Hallo wereld"`. Strings zijn *onveranderlijk*: je past ze niet aan, je maakt een nieuwe.

## Een string aanmaken

1. Met enkele aanhalingstekens: `'tekst'`
2. Met dubbele aanhalingstekens: `"tekst"`
3. Met drie aanhalingstekens voor meerdere regels

## Veelgebruikte bewerkingen

- **Samenvoegen** met `+`
- Lengte opvragen met `len()`
- *Slicing* om een deel op te vragen

```python
naam = "Python"
print("Hallo, " + naam)
print(len(naam))
```

### String-methodes

| Methode | Beschrijving |
|---|---|
| `.upper()` | Hoofdletters |
| `.lower()` | Kleine letters |

Meer info: [Python documentatie](https://docs.python.org/3/library/stdtypes.html#string-methods).

GitHub Desktop¶

We hebben een Git repo in GitHub en kunnen daar 'online' bestanden in de repo bewerken. Maar het is natuurlijk veel handiger om lokaal te werken in een 'echte' editor zoals VS Code of PyCharm.

Hoe krijgen we de Git repo vanop GitHub lokaal?

Op de GitHub pagina van de repo zien we een groene <> Code knop. Die biedt heel wat opties - o.a.

• Clone: is een Git concept waarbij je, zoals de naam doet vermoeden, een kloon krijgt van de volledige repo. Hiervoor hebben we Git software (client) nodig op onze computer, en dat is nu nog niet het geval.
• Download ZIP: laat toe om een ZIP bestand te downloaden met daarin alle bestanden in de repo.

Installatie¶

GitHub Desktop is een Git client waarmee je op een visuele manier kan werken met GitHub (of een andere Git server). Dit is een eenvoudige manier om lokaal van start te gaan met Git.

GitHub Desktop is beschikbaar voor Windows en macOS en kan je downloaden via bovenstaande link.

Tijdens de installatie kies je ervoor om in te loggen op GitHub (Sign in to GitHub.com) en GitHub Desktop toegang te geven tot je GitHub account.

In het Configure Git dialoogvenster kan je ervoor kiezen een andere naam te gebruiken (dan je GitHub account naam) om je commits te ondertekenen. Het is wel belangrijk dat je hetzelfde email adres gebruikt als je GitHub account.

Repo Clonen¶

Op het startscherm van GitHub Desktop krijg je een lijst met al je repos in GitHub. Je hebt ook nog andere opties om een repo toe te voegen maar om te starten selecteer je de repo die we zonet in GitHub hebben aangemaakt.

Eenmaal geselecteerd verschijnt onderaan een knop om de repo lokaal te clonen. Vervolgens kan je kiezen waar je de repo op je lokale drive wil plaatsen. Misschien heb je al een folder met je programmeerprojecten maar anders is de voorgestelde locatie ok.

GitHub Desktop opent nu je lokale clone.

Op de History tab kan je alvast de bestaande commits in de repo herbekijken. Als alles goed is komt dit overeen met wat we in GitHub gedaan hebben.

Repo in Editor Openen¶

Terug op de Changes tab krijg je de optie om de repo te openen in VS Code. In de instellingen (CTRL+, of CMD+,) heb je onder Integrations de optie een andere editor in te stellen. Je kan natuurlijk ook vanuit VS Code zelf de folder van de repo rechtstreeks openen.

Lokale Aanpassingen¶

Gebruik je editor om een paar willekeurige aanpassingen te maken in het README.md bestand. Voeg ook in een nieuwe bestand een eenvoudig Python programma toe, bvb:

def hello(name):
    print(f"Hello there {name}!")

hello("Syntra")

Vergeet beide bestanden niet op te slaan (CTRL+S of CMD+S)!

Terug in GitHub Desktop merk je dat de aanpassingen automatisch zijn waargenomen en geselecteerd (aangevinkt) om gecommit te worden. Naast test.py staat een icoon, omdat dit een volledig nieuw bestand is. Naast README.md staat omdat dit bestand gewijzigd is.

Links onderaan kan je de aanpassingen committen.

Oefening¶

Deel de URL van je GitHub repo (bvb https://github.com/dvx76/git-demo) met je buur. Probeer dan uit te zoeken hoe je met GitHub Desktop de repo van iemand anders lokaal op je eigen systeem kan clonen. Maak gerust gebruik van een zoekopdracht of AI om je op weg te helpen.

Eenmaal gecloned open je de repo in VS Code en maak opnieuw een paar aanpassingen. Probeer die aanpassingen te committen. Bedenk op voorhand of dit wel zal lukken...

Als het lukt probeer je de nieuwe commit naar de GitHub repo te sturen (push). Maak opnieuw dezelfde bedenking op voorhand. Bespreek de resultaten klassikaal.

Samenvatting¶