Git i CI per a processos Oracle

Traçabilitat, revisió i automatització

Raúl Salinas Monteagudo

2026-09-16

Objectiu

Què volem aconseguir?

Una font de veritat per als scripts
Historial dels canvis
Revisió entre companys abans d’executar
Validacions automàtiques
Menys coneixement tàcit: el que només està en un cap

Millora operativa, no crítica a la manera actual de treballar.
Font de veritat no és on es guarda: és qui mana i com es comprova. Hui, «quina és la versió correcta?» no té resposta; les cinc opcions de la diapositiva següent són totes plausibles.
- i es pot preguntar en qualsevol moment si la teua còpia coincidix: git status, git diff
- amb una carpeta compartida eixa pregunta ni tan sols es pot formular
Va la primera perquè les altres quatre la necessiten: revisar exigix saber contra què, validar exigix saber què, l’historial exigix una sola línia de descendència.
De les cinc, la revisió entre companys és l’única que canvia com es treballa amb altra gent, i per tant l’única que genera renuència: dir-la pel seu nom i passar. Es desactiva després, en el bloc de revisions.
El coneixement tàcit demana un exemple o dos, que el terme a soles no diu res:
- l’ordre real de les passes, que no és el del document
- el paràmetre que cal canviar cada any i no està escrit enlloc
- saber quin dels tres scripts amb nom paregut és el bo
El perill: qui el té creu que és obvi, i per això no el conta.
L’apartat no s’imparteix: esta és l’única vegada que es diu el nom.

Com anirà el matí

Hora	Bloc	Pràctica
10:00–10:15	Per què: problemes operatius i el patró habitual	—
10:15–11:00	Git essencial: el cicle mínim, veure què ha canviat, recuperar una versió	Exercici 1
11:00–11:45	Branques, conflictes i revisió entre companys	Exercicis 2, 3 i 3b
11:45–11:55	Pausa
11:55–12:15	Què versionem d’Oracle, què no hi va mai, quants repositoris	—
12:15–12:45	Entorn de proves efímer, dades sintètiques i traçabilitat	Demostració
12:45–12:55	Pausa
12:55–13:35	Integració contínua: què comprova i els tres nivells	Exercici 5
13:35–13:50	Per on començar: el primer pilot	—
13:50–14:00	Tancament i preguntes

Pareu-me quan vulgueu: els dubtes en veu alta són part del curs.

On està tot

Manual, diapositives, exercicis i xuleta de comandes, en el zip del curs.

L’enunciat de cada pràctica està en Exercicis, amb les comandes per a copiar.

Què no us demane

No cal que munteu cap entorn ni instal·leu cap base de dades
L’Oracle de proves el veureu en pantalla: el munte jo
Els exercicis són de Git i de revisió: repositori, branca, pull request

Si ja useu Git

En esta sala hi ha qui l’usa cada dia i qui no l’ha obert mai. Els primers blocs són per als segons.

Encara que Git us sone, probablement no heu fet mai:

integració contínua: que cada canvi es valide a soles, sense que ho demane ningú
fer eixes mateixes comprovacions en la teua màquina, abans del commit
validar SQL contra un Oracle que es crea i es destruïx en cada execució
versionar el que no se sol versionar: DDL, dades mestres, rols, grants, jobs
saber què no recupera Git quan el canvi ja s’ha executat sobre dades reals

Problema

On és la versió correcta?

Directori personal
Servidor de producció
Correu electrònic
Historial del terminal
script_final_bueno_2.sql

Un patró habitual

En carpetes que han crescut durant anys:

informe.sql
informe_v2.sql
informe_final.sql
informe_final_bueno.sql

el nom fa de control de versions, perquè no n’hi ha cap altre
i, abans que tot això: cada u té la seua còpia, i ja no es poden comparar

Un sol fitxer

git log --oneline -- informe.sql   # totes les versions: data, autor i motiu
git show HEAD~3:informe.sql        # com estava fa tres canvis
git diff HEAD~3 -- informe.sql     # què ha canviat des d'aleshores

Quatre fitxers passen a ser un, i no es perd cap versió.

De procediments manuals a canvis traçables

Tiquet
  ↓
Branca
  ↓
Canvi
  ↓
Pull request
  ↓
CI
  ↓
Revisió
  ↓
Versió aplicada

Per ací passen les ferramentes: scripts, esquemes, configuració. Una tasca —un canvi fet a mà— no hi passa: usa una ferramenta, i queda al registre.

La integració contínua (CI) vol dir que, cada vegada que algú puja un canvi, s’executa a soles un codi que el comprova. Eixe codi és la pipeline, i viu versionada en el repositori com qualsevol altra cosa.

Obrir amb el cas real: arriba una tasca, s’obri un SQL Developer, es fa l’UPDATE i no queda constància de res. Ni què es va executar, ni quina versió, ni per què.
La distinció que ho ordena tot:
- una tasca és fer una cosa concreta (canviar el nom d’un usuari). S’executa.
- una ferramenta és l’script que fa eixe tipus de coses. Es desenvolupa.
El diagrama és la vida d’una ferramenta. Una tasca no hi passa: usa una ferramenta, i la seua traça és el tiquet + el registre d’execució (el commit= del log, que ix després).
El verb que les lliga: convertir. Una tasca a mà una vegada, cap problema. La segona vegada que es fa el mateix UPDATE a mà, està demanant ser una ferramenta. Ahí entra en l’esquema.
Este esquema és el guió del matí: cada fletxa és un bloc del curs. No cal que tot canvi passe per la cadena sencera; el que importa és que el camí existisca i siga el mateix per a tothom.
Integració contínua, definida ací perquè la paraula ix abans: cada vegada que algú puja un canvi, s’executa a soles un codi que el comprova. Eixe codi és la pipeline, versionada al repositori.
La frase que resumix el curs: no vos propose que useu Git; vos propose que tractem la faena d’operacions com a programari.
Com dir-ho:
- la urgència de matinada no cal nomenar-la: amb la distinció ja queda contestada (és una tasca)
- el tiquet és de la tasca; Git és de la ferramenta. Si ix el ticketing, eixa és la frase

Git essencial

Aconseguir el repositori

git clone https://bitbucket.org/uveg/curs-git-ci-oracle.git
cd curs-git-ci-oracle

Un clon no és una descàrrega: et portes l’historial sencer, i pots treballar sense xarxa.

git config --global user.name "Nom Cognom"
git config --global user.email "usuari@uv.es"

Per a començar un repositori de zero, git init dins de la carpeta.

Un clon no és una descàrrega: et portes l’historial sencer, i això és el que permet veure quins canvis s’han fet, quan, per què i per qui. Per això es pot treballar sense xarxa.
El config no és opcional, i dir el perquè: és el que fa que els commits duguen el teu nom.
- amb compte compartit, si no es posa, tots els commits els firma el mateix usuari
- és un error que no es nota fins mesos després, quan mires l’historial per a saber qui va fer una cosa i tot diu el mateix
Ací va el nom i el correu. La contrasenya no. He vist gent posant la contrasenya en el user.name i fent un commit després: eixa contrasenya se’n va a l’historial per sempre.
- enganxa amb la diapositiva «Si un secret ja ha entrat», on es pot tancar: «recordeu el que vos deia al principi?»
Com dir-ho:
- les cinc preguntes que contesta l’historial són les del commit, que ix més avant: «això que vos deia al clonar»
- no entrar en l’intèrpret d’ordres. Si molesta no dir-ho: «les cometes són perquè hi ha un espai», i avant
- git init al final, curt, enllaçant amb la portada

Què tinc ara mateix?

$ git status

Changes to be committed:          ← triat per al pròxim commit
        modified:   consulta_tablespaces.sql

Changes not staged for commit:    ← tocat, però encara no triat
        modified:   validacio_cites.sql

És la comanda que més usareu, i anomena ella mateixa les dues zones.

Les tres zones

directori de treball  ──git add──>  zona de preparació  ──git commit──>  historial
      (el que edites)                  (el que entrarà)                  (permanent)

git add no guarda res: tria què entrarà en el pròxim commit
per això es poden fer dos commits separats de dos canvis del mateix fitxer
git status diu sempre en quina zona està cada cosa

El cicle mínim

git pull
git status
git diff
git add fitxer.sql
git commit -m "Afig validació de cites duplicades"
git push

Són sis ordres i cobrixen el 90% de l’ús diari.
pull obri el cicle: posar-se al dia abans de tocar res. En els exercicis treballem trenta persones sobre el mateix repositori, així que no és opcional — sense això, el push del final rebota.
Per què status primer: per a començar amb el repositori net. O t’has deixat una cosa pendent d’una altra sessió que volies pujar en el seu propi commit, o has tocat alguna cosa sense voler i la vols desfer abans de seguir.
git diff és el diff de tota la vida: les línies que has tocat.
add del fitxer sencer. Per trossos, al final del bloc.
Si no li poses -m, s’obri un editor. Per això l’enunciat els fa posar EDITOR abans de començar: perquè s’òbriga el que usen ells.
I el final, que és l’error número u de qui comença: fins ací només hi ha un commit local. No està en cap servidor i cap company el veu. Fa falta push.
Com dir-ho:
- escriure-ho en directe, no llegir-ho de la pantalla
- un commit no és un pedaç: el pedaç és el diff
- «feu status abans i després de cada passa» — al principi és el que orienta

Què aporta un commit?

Un canvi d’una línia en la comprovació de tablespaces:

-LLINDAR_OCUPACIO=85
+LLINDAR_OCUPACIO=90

	El commit ho contesta
Què ha canviat	`LLINDAR_OCUPACIO`, de 85 a 90
Qui ho ha fet	l’autor del commit
Quan	la data i l’hora exactes
Per quin motiu	«Puja el llindar d’avís de tablespaces (INC-0912)»
Com tornar arrere	`git revert a183fe2`

El commit, per dins

$ git show -s --format=raw a183fe2
commit a183fe2c9b4d7e1a6f3c8b2d5e9a0f4c7b1d6e38
tree 9c1b7a4f2e5d8c0a1b3e6f7d2c4a8b9e0f1d3c5a
parent 4f2a1c8e7b3d9a0f6c5e2d4b8a1f7c3e9d0b6a2f
author Raúl Salinas <raulsa8@uv.es> 1788249600 +0200
committer Raúl Salinas <raulsa8@uv.es> 1788249600 +0200

    Puja el llindar d'avís de tablespaces de 85 a 90 (INC-0912)

`commit`	el hash: no és un número de sèrie, ix del contingut
`tree`	la fotografia completa del projecte, no el canvi
`parent`	el commit anterior: ací es forma la cadena
`author` / `committer`	qui el va escriure i qui el va aplicar: difereixen si el commit s’ha reaplicat (`rebase`, `cherry-pick`)
el missatge	l’única part que no es pot deduir mirant el codi

Per a què és esta diapositiva: perquè no hi ha màgia. Són sis línies de text, i dues d’elles importen.
parent és la que compta: el commit anterior. Ací es forma la cadena, i esta línia és tota la teoria de branques. Assenyalar-la amb el dit i tornar-hi quan isca el dibuix.
- la frase: un commit no és un canvi; és una foto amb una fletxa cap a la foto anterior. El canvi és el que hi ha entre les dues
El hash ix del contingut, no és un número de sèrie que assigne ningú. Canvia una coma i canvia el hash: per això no es pot falsificar l’historial sense que es note.
tree és la fotografia sencera del projecte en eixe moment. Una frase i avant: no s’usa mai en el dia a dia i fa falta --format=raw per a veure-la. El que explica és que el commit no guarda el diff, i per això git show HEAD~3:informe.sql és instantani.
author / committer: difereixen quan un commit es torna a aplicar, no quan es fusiona.

Operació	`author`	`committer`
`rebase` de la branca d’un company	el company	tu
`cherry-pick` d’un commit seu	el company	tu
aplicar un pedaç per correu (`git am`)	qui el va escriure	tu
commit de fusió (`merge`)	tu	tu

En una fusió, el commit de fusió és tot teu i els commits fusionats conserven el seu autor intacte: és el que promet la diapositiva de fusionar.
Com dir-ho:
- el --format=raw fa falta perquè git show per defecte amaga tree i parent i fon author i committer en una línia
- si pregunten si Git guarda increments: el model és de fotografies; el magatzem sí que comprimix amb deltes en empaquetar, però és una capa de baix. I la foto no costa una còpia: un fitxer que no canvia és el mateix blob en els dos commits. Contestar això i passar

Què ha canviat un company?

git diff                    # el que he tocat jo
git diff main...validacio-cites   # tot el que aporta una branca
git show a183fe2            # un canvi concret, amb el seu motiu

La vista d’una pull request és això mateix, en el navegador i amb un lloc per a comentar cada línia.

La pregunta real de l’equip no és «què és un diff?», sinó «un company ha canviat el procés de càrrega: què ha tocat exactament?».
És probablement la utilitat que més es nota el primer dia.
L’última línia és la que val: la vista d’una pull request és exactament això, i per això la revisió no obliga a llegir el fitxer sencer.
Com dir-ho:
- main...branca du tres punts, i si algú ho pregunta —els que programen ho preguntaran— la resposta és una frase:
  - dos punts: main d’ara contra la branca d’ara
  - tres punts: main de quan es van separar, contra la branca d’ara
  - o siga: el tercer punt recula el main. La branca no es mou mai
- per què importa: amb dos punts ixen també els canvis que ha fet main mentrestant, i del revés, com si la branca els haguera esborrat. Com més temps porte oberta la branca, més brossa
- eixe punt de separació es diu merge base (git merge-base main branca)
- no cal explicar-ho si no ho pregunten: en el dia a dia ningú escriu això, s’obri la pull request i ja està fet

Funcionava fa una setmana

git log --oneline -- validacio_cites.sql
git show a183fe2
git blame create_user.sql

Git no sols permet tornar arrere: permet reconstruir com hem arribat ací.

Mirar, restaurar, revertir

Vull…
Mirar com estava	`git show HEAD~3:informe.sql`
Tornar el fitxer enrere	`git restore --source=HEAD~3 informe.sql`
Desfer un canvi ja integrat	`git revert a183fe2`

En una branca compartida, sempre git revert.

Les tres es confonen constantment. Mirar no toca res; restaurar canvia el fitxer que tens davant; revertir afig un commit.
git revert és com els auriculars amb cancel·lació de soroll: genera un commit amb els canvis justament inversos, de manera que la suma dels dos deixa el fitxer com estava.
- i el matís: en absència d’altres canvis. Si algú ha tocat eixes línies després, el revert pot donar conflicte
Per què en branca compartida sempre revert: perquè afig en compte de reescriure, i per tant no trenca la còpia de ningú.
Com dir-ho:
- HEAD és on estàs ara. Si pregunten per les notacions:
  - ^ tria quin pare (només importa en una fusió, que en té dos)
  - ~n compta quantes generacions arrere, seguint sempre el primer pare
  - en historial lineal coincidixen: HEAD^ és HEAD~1. Per això semblen el mateix
  - @ a soles és un àlies de HEAD; HEAD@{2} és una altra cosa, el reflog
- no enumerar totes les notacions: és un pou. En l’exercici els fem copiar el hash, que no depén de comptar
- no dir que git show compara: show mostra el contingut d’eixa versió. La que compara és git diff HEAD~3 -- informe.sql

El repositori remot

git remote -v        # a on apunte
git fetch            # baixa el que hi ha, sense tocar-me res
git pull             # fetch + integrar-ho en la meua branca
git push             # pujar el que he consolidat

$ git remote -v
origin  https://bitbucket.org/uveg/curs-git-ci-oracle.git (fetch)
origin  https://bitbucket.org/uveg/curs-git-ci-oracle.git (push)

El teu clon i el servidor són dos repositoris complets. fetch només mira; pull a més integra.

Dos repositoris complets: no sou un client d’un servidor, teniu una còpia sencera amb tot l’historial. Per això es pot treballar sense xarxa —en un avió, fent commits— i sincronitzar després.
origin és només un nom, el que li posa clone per conveni. Es pot renomenar i no passa res.
Es pot tindre cap remot o més d’un. Un repositori local sense remot no és inútil: per a un projecte personal o una documentació, ja val només per a poder tornar arrere.
La distinció fetch/pull: es pot mirar què ha passat sense que et toquen els fitxers.
I explica per què de vegades el push es rebutja: no és un error teu, és que algú ha pujat abans i el teu clon està endarrerit. Cal integrar primer.
Com dir-ho:
- si pregunten quines branques es baixa el fetch: totes. El clone escriu un refspec amb un asterisc (+refs/heads/*:refs/remotes/origin/*). Es pot restringir, però no és el normal

I el git add? git commit -a se salta la preparació. Però amb quatre passes ja no és un cartell.

Les tres que es confonen

	Què toca	Quan
`git restore fitxer`	el teu directori	m’he equivocat i encara no he fet commit
`git reset --soft HEAD~1`	l’historial local	el commit era prematur; els canvis es queden
`git reset --hard HEAD~1`	historial i fitxers	no vull res del que he fet ⚠️
`git revert a183fe2`	afig un commit nou	ja està integrat i ho vol desfer tothom

reset reescriu; revert afig. En allò que ja han baixat altres, sempre revert.

La regla de decisió és una pregunta: ho ha vist algú més? Si no, reset. Si sí, revert. Amb això ja se’n poden anar.
El --hard és l’única comanda del curs que perd faena de veres i sense avisar. Dir-ho clar.
--soft servix per a refer el commit: els canvis es queden preparats i en pots fer un altre, per exemple amb un missatge millor. (git commit -C <hash> reaprofita el missatge d’un altre.)
Com dir-ho:
- la frase és «no es lleva: s’afig un altre que el revertix». No dir «no es pot esborrar»: es pot, amb push --force, i es contradiria amb la diapositiva de reescriure l’historial. En main el servidor ho impedix
- hi ha un tercer reset, --mixed, que és el que ix per defecte: git reset HEAD~1 a soles desfà el commit, trau els canvis de la zona de preparació i deixa els fitxers intactes. És el que pisaran sense voler
- matís de restore, per si algú el nota: restaura des de l’índex, no des del commit. Coincidixen mentre no hages fet add

M’han interromput

git stash            # guarda el que tinc a mitges i deixa el directori net
git switch main      # atenc la urgència
git stash pop        # torne a on estava

Per a quan et criden a mitjan canvi i has de mirar una altra cosa ara.

La comanda que més s’agraïx el primer mes.
El cas passa cada setmana: estàs a mitges i entra una incidència.
Sense Git: copiar el directori i intentar recordar després què havies tocat.
És una pila: se’n poden apilar diversos i pop recupera l’últim. Amb git stash push -m "..." se li pot posar missatge.
Stash o commit a mitges? Minuts i mateixa branca → stash. D’una vesprada cap amunt → commit: sobreviu, es pot pujar com a còpia de seguretat, i després es neteja amb rebase -i.
Com dir-ho:
- el stash és local i no es comparteix: és una butxaca per a una estona, no un lloc on guardar faena
- un stash oblidat no avisa; un commit el veus en el git log
- trampa que val la pena dir: git stash no s’emporta els fitxers nous (sense seguiment). Per a endur-se’ls, git stash -u

Revertir un commit recupera el codi, no les dades.

Un UPDATE o un DDL ja executat no es desfà amb Git.

D’ací ix una decisió: els processos amb dades reals acaben amb una persona que decidix.

No explicar-ho com si no ho saberen. Obrir reconeixent-ho: «una cosa que és evident però que convé deixar dita, perquè ens farà falta després».
No corregix ignorància: interromp un reflex. Portem sis diapositives dient «açò es desfà», i la sensació que queda és que tot té marxa arrere.
La part que val és la conseqüència, no el fet: d’ací ix el botó humà de la part d’automatitzar. Sense això, «entrega contínua amb decisió humana» sona a prudència arbitrària.
Si algú demana com es recupera l’esquema: és un problema distint, amb les seues ferramentes —migració compensatòria, Flashback, restauració—. Està al manual.
I el cas que tanca la discussió: si el DDL esborrava una columna, revertir l’script torna un script que la torna a crear. Buida. Les dades que hi havia mai han estat en Git.
Com dir-ho:
- vint segons, to de qui estableix un supòsit, no de qui ensenya
- no entrar en ferramentes de comparació d’esquemes. Si ho pregunten: «n’hi ha que ho calculen; és una conversa per al pilot»

Reescriure l’historial

commit --amend, rebase -i i filter-repo no modifiquen commits: en creen d’altres i abandonen els vells.

Branca	Reescriure
`main` i les compartides	Mai. Per a desfer, `git revert`
La teua, encara sense fusionar	Endavant, i sovint convé

publicar-ho exigix git push --force: «descarta el que hi ha al servidor»
les branques principals es protegixen, i el servidor el rebutja
si has de forçar: --force-with-lease, que falla si algú havia pujat res

Els que programen preguntaran per això, així que val més tindre-ho.
El cas legítim és la branca pròpia: mentre proves, els commits són «ara sí», «prova 3», «torna arrere lo d’abans».
- eixe historial no ajuda ningú a revisar
- rebase -i els ajunta en un o dos que expliquen el canvi de veres
El que revisa el company és això, no el camí que vas fer.
Que no et deixe forçar main no és una limitació: és la xarxa funcionant.
Què li passa al company que ja tenia el commit vell (comprovat): el seu pull falla amb refusing to merge unrelated histories. El commit del qual penjava ja no existix, així que per a Git són dues històries sense res en comú.
- es queda bloquejat: o força la integració i acaba amb els dos commits duplicats, o…
- …fa push per a desatascar-se i ressuscita el commit vell en el servidor, desfent la teua reescriptura
--force-with-lease, dit en una frase:
- --force: «posa la branca ací, hi haja el que hi haja»
- --force-with-lease: «posa-la ací només si el servidor segueix on jo el vaig veure». Si no, rebutja amb stale info
- es diu lease perquè l’últim fetch et dona una espècie de contracte temporal sobre l’estat del remot; si algú l’ha canviat, ha caducat
- si has de forçar, sempre este. Fa el mateix quan no hi ha ningú més i et salva quan sí que n’hi ha
Com dir-ho: si es demostra en directe, el que impressiona és el refusing to merge unrelated histories del company: es veu que el problema no és teu, és seu.

Què forma realment el projecte

git ls-files              # l'inventari: el que algú va decidir que hi forma part
git ls-files '*.sql'      # només el SQL
git grep DBMS_SCHEDULER   # buscar només dins d'eixe inventari

ls mostra el que hi ha. git ls-files mostra el que s’ha decidit tindre.

El .gitignore és l’altra cara: deixa fora generats, logs i temporals.

El missatge diu per què

Canvia timeout a 60
Evita timeout durant la càrrega de matrícula (INC-1234)

el què ja el diu el diff
el per què no està en cap altre lloc
un commit, una cosa: barrejar-ho tot encarix llegir-lo, revisar-lo i desfer-lo
en present: «Afig…», que en valencià val alhora d’imperatiu. Mai infinitiu ni passat
Conventional Commits (feat:, fix:) calcula versions d’un producte que es publica: ací no compra res

Obrir dient que es canvia de nivell: «fins ara, què és un commit; ara, com s’escriu». Si no, pareix que es torna arrere.
Mesos després, per què eixe valor és 60? La resposta ha d’estar a un git show de distància.
El motiu importa sobretot quan toca el codi més gent: el missatge és l’únic lloc on viu la intenció.
Els commits menuts abaraten la revisió, i per això la revisió es fa.
Si pregunten per la forma verbal o per Conventional Commits —i ho preguntaran—:
- present: «Afig…», que en valencià val alhora d’imperatiu
- compte: en anglés la forma d’infinitiu i la d’imperatiu coincidixen (add), per això dona igual. En valencià no: afegir i Afig són distintes, i la bona és la segona
- la idea de fons: el commit fa una cosa, no ha fet una cosa
- Conventional Commits calcula versions de productes que es publiquen; ací no es fa. L’enllaç de la diapositiva s’obri si convé: és una pàgina curta
El desenvolupament està al manual. En la sessió no gastar-hi temps.

Dos canvis en un mateix fitxer

Has afegit una funcionalitat i has arreglat el fallo que t’ho impedia. Són dos commits.

git add -p consulta_tablespaces.sql

Git va mostrant els canvis tros a tros i pregunta per cada u:

Stage this hunk [y,n,q,a,d,s,e,?]?

y sí · n no · s parteix el tros en trossos més menuts

Ara sí que es pot dir, perquè ja saben per a què volen commits menuts.
El cas és el de tots els dies: anaves a fer una cosa i pel camí n’has hagut d’arreglar una altra. Sense això, o ix un commit que barreja, o es perd l’arreglament.
Ací es veu per què add tria i no guarda: la tria pot ser més fina que el fitxer.
Com dir-ho:
- demostració en directe, que llegit no es veu: dos canvis en un fitxer, add -p, y a un i n a l’altre, status i commit
- p és de --patch, per si ho pregunten
- s i e no són el mateix: s (split) partix el tros a soles, i només pot quan entre els dos canvis hi ha alguna línia sense tocar. e (edit) l’obri en l’editor i es tria línia a línia: és el que fa falta quan els dos canvis són contigus
- o siga: primer s; si diu que no pot, e
- el motiu que més pesa ací no és l’estètica: és que després es puga entendre i auditar el que es va fer

Practiquem: exercici 1

Entendre el cicle modificar → revisar → commit.

export UVLOGIN=raulsa8              # ← el vostre
git config --global core.editor nano

L’editor es posa amb git config: és de Git, no del terminal, i no cal repetir-ho.

L’enunciat dona per fet un terminal tipus Unix —Git Bash, WSL, MobaXterm—. Si no, hi ha l’alternativa escrita.

Enunciat: el document Exercicis del material del curs

L’editor es posa amb git config, no amb una variable del terminal: es guarda i no cal repetir-ho en cada finestra nova.
Preguntar qui no té un terminal tipus Unix abans de començar: Git Bash ve amb Git per a Windows, i també val WSL o MobaXterm. És el moment de detectar-ho, no a mitjan exercici.
- en PowerShell la variable és $env:UVLOGIN = "raulsa8"; l’enunciat ho du
- i sempre es pot escriure l’identificador a mà on pose $UVLOGIN
Si obrin un terminal nou, han de repetir l’export. L’editor no, que és configuració de Git.
Este primer commit va en el seu main local, i és a posta: les branques encara no s’han explicat. Dir-ho, que si no algú es preguntarà si ho està fent mal.
- el main del servidor no el toca ningú: l’únic push del matí és el de la seua branca
No passar de diapositiva fins que algú diga que ha acabat; si ningú diu res, preguntar-ho.

Branques i revisió

L’historial és una cadena

graph RL
  classDef commit fill:#002e52,stroke:#002e52,color:#fff;
  classDef punter fill:#e4ebe9,stroke:#002e52,color:#002e52,stroke-width:2px;
  c3(( )) --> c2(( )) --> c1(( ))
  main["main"] -.-> c3
  class c3 commit;
  class c2 commit;
  class c1 commit;
  class main punter;

Cada cercle és un commit, i apunta al que tenia darrere: és la línia parent.

main no és una carpeta ni una còpia: és un punter a l’últim commit.

Una branca és un punter nou

git switch -c validacio-cites

graph RL
  classDef commit fill:#002e52,stroke:#002e52,color:#fff;
  classDef punter fill:#e4ebe9,stroke:#002e52,color:#002e52,stroke-width:2px;
  c3(( )) --> c2(( )) --> c1(( ))
  main["main"] -.-> c3
  vc["validacio-cites"] -.-> c3
  inf["informes"] -.-> c2
  class c3 commit;
  class c2 commit;
  class c1 commit;
  class main punter;
  class vc punter;
  class inf punter;

Tres branques, tres punters. validacio-cites i main assenyalen el mateix commit; informes es va quedar arrere.

No s’ha copiat cap fitxer: només hi ha un nom nou.

Els teus commits van a la teua branca

graph RL
  classDef commit fill:#002e52,stroke:#002e52,color:#fff;
  classDef punter fill:#e4ebe9,stroke:#002e52,color:#002e52,stroke-width:2px;
  c4(( )) --> c3(( )) --> c2(( )) --> c1(( ))
  main["main"] -.-> c3
  vc["validacio-cites"] -.-> c4
  inf["informes"] -.-> c2
  class c4 commit;
  class c3 commit;
  class c2 commit;
  class c1 commit;
  class main punter;
  class vc punter;
  class inf punter;

El mateix dibuix, amb un commit més. S’ha mogut un sol punter: el teu.

main i informes estan exactament on estaven. Ningú més veu encara els teus canvis.

Mentrestant, main avança

%%{init: {'theme':'base','themeVariables':{'git0':'#002e52','git1':'#0082c5','gitBranchLabel0':'#ffffff','gitBranchLabel1':'#ffffff','commitLabelColor':'#002e52','commitLabelBackground':'#e4ebe9','commitLabelFontSize':'15px'},'gitGraph':{'showCommitLabel':false,'showBranches':true}}}%%
gitGraph
   commit id: "a183fe2"
   commit id: "d4e5f6a"
   commit id: "3e88c17"
   branch validacio-cites
   checkout validacio-cites
   commit id: "9f01aa3"
   commit id: "7c22bd1"
   checkout main
   commit id: "b7d3e90"

Les dues històries han divergit. És el cas normal quan treballa més d’una persona, no una avaria.

Fusionar

%%{init: {'theme':'base','themeVariables':{'git0':'#002e52','git1':'#0082c5','gitBranchLabel0':'#ffffff','gitBranchLabel1':'#ffffff','commitLabelColor':'#002e52','commitLabelBackground':'#e4ebe9','commitLabelFontSize':'15px'},'gitGraph':{'showCommitLabel':false,'showBranches':true}}}%%
gitGraph
   commit id: "a183fe2"
   commit id: "d4e5f6a"
   commit id: "3e88c17"
   branch validacio-cites
   checkout validacio-cites
   commit id: "9f01aa3"
   commit id: "7c22bd1"
   checkout main
   commit id: "b7d3e90"
   merge validacio-cites

M és un commit amb dos pares. Per això no es perd res de cap de les dues bandes.

Moure’s entre branques

git branch                    # quines tinc
git branch -a                 # també les del servidor
git switch validacio-cites    # canviar-me
git switch -c nova            # crear-la i canviar-me
git switch -                  # tornar a l'anterior

git checkout fa això mateix i moltes coses més: switch i restore el partiren en dos, precisament perquè confonia.

Val la pena dir-ho perquè tota la documentació antiga i tot el que trobaran en internet usa checkout. Que sàpien que no estan equivocats, que és el mateix, i que switch és el nom modern.

Si pregunten per què el partiren (dos motius concrets, no estètics):
- git checkout nom és ambigu si hi ha una branca i un fitxer que es diuen igual
- git checkout -- fitxer destruïx canvis no comitejats sense avisar ni deixar rastre, i està a un guionet de l’anterior. switch (branques) i restore (fitxers) separen les dues coses
Si els ix detached HEAD: vol dir que HEAD apunta a un commit i no a cap branca. Passa amb git checkout <hash>, amb una etiqueta, amb git checkout origin/main, durant un rebase o un cherry-pick amb conflicte, amb git bisect, i en molts clons de CI. No s’ha trencat res: se’n ix amb git switch -, o amb git switch -c nova si es vol conservar el que s’ha fet ahí.

Dues maneres d’integrar

El mateix punt de partida: la teua branca i main han divergit.

%%{init: {'theme':'base','themeVariables':{'git0':'#002e52','git1':'#0082c5','gitBranchLabel0':'#ffffff','gitBranchLabel1':'#ffffff','commitLabelColor':'#002e52','commitLabelBackground':'#e4ebe9','commitLabelFontSize':'15px'},'gitGraph':{'showCommitLabel':false,'showBranches':true}}}%%
gitGraph
   commit id: "o"
   commit id: "o"
   branch branca
   checkout branca
   commit id: "A"
   commit id: "B"
   checkout main
   commit id: "X"
   commit id: "Y"

Per a incorporar X i Y al teu treball hi ha dos camins, i no fan el mateix.

Opció A: `git merge main`

%%{init: {'theme':'base','themeVariables':{'git0':'#002e52','git1':'#0082c5','gitBranchLabel0':'#ffffff','gitBranchLabel1':'#ffffff','commitLabelColor':'#002e52','commitLabelBackground':'#e4ebe9','commitLabelFontSize':'15px'},'gitGraph':{'showCommitLabel':false,'showBranches':true}}}%%
gitGraph
   commit id: "o"
   commit id: "o"
   branch branca
   checkout branca
   commit id: "A"
   commit id: "B"
   checkout main
   commit id: "X"
   commit id: "Y"
   checkout branca
   merge main

no reescriu res: A i B es queden com van passar
M té dos pares, i per això l’historial mostra que hi va haver dues línies
els conflictes es resolen una vegada, en el moment de fusionar

Opció B: `git rebase main`

Després de git rebase main, la teua branca ix d’on acaba main:

%%{init: {'theme':'base','themeVariables':{'git0':'#002e52','git1':'#0082c5','gitBranchLabel0':'#ffffff','gitBranchLabel1':'#ffffff','commitLabelColor':'#002e52','commitLabelBackground':'#e4ebe9','commitLabelFontSize':'15px'},'gitGraph':{'showCommitLabel':false,'showBranches':true}}}%%
gitGraph
   commit id: "o"
   commit id: "o"
   commit id: "X"
   commit id: "Y"
   branch branca
   checkout branca
   commit id: "A'"
   commit id: "B'"

els teus commits es tornen a aplicar damunt de main
A' i B' són commits nous: mateix contingut, hash distint
l’historial queda lineal, com si hagueres començat hui

Quina trie?

	`merge`	`rebase`
L’historial	fidel: es veu que hi va haver dues línies	lineal i fàcil de llegir
Els teus commits	queden intactes	es reescriuen, amb hash nou
Conflictes	es resolen una vegada	poden repetir-se commit a commit
Es veu quan es va integrar	sí	no, es perd
En una branca compartida	segur	mai

La regla: rebase només en la teua branca, i només mentre no l’haja baixada ningú.

La recomanació per a nosaltres

per a integrar: merge. És segur i no cal pensar-hi
per a netejar la teua branca abans de la pull request: rebase -i
per a posar-te al dia sense omplir l’historial de fusions: git pull --rebase

I això no cal dibuixar-ho

git log --graph --oneline --all

*   ffff11 Merge branch 'validacio-cites'
|\
| * 7c22bd Afig validació de cites duplicades
* | 3e88c1 Reescriu la condició de duplicats (INC-1234)
|/
* a183fe2 Documenta consulta de tablespaces

Pull request

Context del canvi
Diferències línia a línia
Comentaris
Aprovació
Evidència de revisió

No és control personal

És:

transmissió de coneixement
detecció d’errors
criteris compartits
continuïtat del servei

I, sobretot: la manera de proposar un canvi en el codi d’un altre sense tocar-li res.

Dos toquen la mateixa línia

Carpeta compartida: l’últim que guarda sobreescriu l’altre. En silenci.

Git: s’atura i obliga a decidir.

<<<<<<< HEAD
WHERE data_inici <= SYSDATE
=======
WHERE data_inici <= TO_DATE('&&data_referencia', 'YYYY-MM-DD')
>>>>>>> validacio-cites

Practiquem: exercicis 2, 3 i 3b

2 — una branca de treball, sense tocar main
3 — obrir una pull request i revisar la d’un company
3b — provocar un conflicte, resoldre’l i recuperar una versió

Enunciat: el document Exercicis del material del curs

☕

Pausa

Tornem a les 11:55

SQL i Oracle

Què podem versionar?

Base de dades

SQL operatiu, informes i extraccions
DDL, migracions i PL/SQL
rols, grants i perfils
jobs de DBMS_SCHEDULER
dades mestres: centres, titulacions, calendaris
validacions de negoci i dades de prova

Què podem versionar?

Sistema

wrappers, crons i systemd
tnsnames.ora i configuració de connexions
inventari de màquines i serveis
Dockerfile i definicions d’entorn
pipelines de CI

Procés

README.md de cada procés
calendari de matrícula, actes, beques
llistes de comprovació
decisions tècniques i el seu motiu

Què no hi va mai

contrasenyes, wallets, claus, tokens
volcats de producció i dades personals
fitxers generats
binaris grans
logs

Dels secrets sí que hi va la referència: quin fa falta i qui el gestiona. Mai el valor.

Si un secret ja ha entrat

Esborrar la línia en el commit següent no el lleva de l’historial.

rotar o revocar la credencial, immediatament
traure-la del codi i posar-la on toca
netejar l’historial, després i si cal

Es versiona la font, no el producte.

Quants repositoris?

La validació sol ser més senzilla quan els components que canvien junts es poden provar de manera coordinada.

Si dues coses que depenen l’una de l’altra estan separades:

cap commit representa “les dues juntes”
un canvi són dues revisions i dues pipelines

Els dos errors no costen igual:

massa junts: ho pagues una vegada, el dia que ho dividisques
massa separats: ho pagues cada vegada que un canvi toque els dos costats

En cas de dubte, menys repositoris dels que sembla que fan falta.

El que canvia junt, viu junt.

Criteris d’organització

Sol convindre organitzar per procés, producte o domini funcional. Menys pràctic:

per persona → pot dificultar la continuïtat
per script → desenes de pipelines i cap canvi transversal
per any → l’any és una etiqueta, no una unitat

La mida no sol ser el criteri

Per a decidir com repartir pesen més:

els permisos i la confidencialitat
els responsables i els cicles de vida
les dependències entre components
la freqüència dels canvis

Un repositori pot ser gran sense que això siga un problema per si mateix.

Exemple: alta d’un usuari

provisioning/users/
├── request.yaml
├── create_user.sql
├── validate_user.sql
└── README.md

`create_user.sql`

WHENEVER SQLERROR EXIT SQL.SQLCODE
WHENEVER OSERROR EXIT FAILURE

-- Exemple docent. No executar en producció sense adaptar-lo.
-- Ús esperat:
-- @create_user.sql APP_ORDENAMAT PROFILE_APPLICATION USERS

DEFINE username = '&1'
DEFINE profile_name = '&2'
DEFINE default_ts = '&3'

CREATE USER &&username
    IDENTIFIED EXTERNALLY
    DEFAULT TABLESPACE &&default_ts
    TEMPORARY TABLESPACE TEMP
    PROFILE &&profile_name;

GRANT CREATE SESSION TO &&username;

Important

Les contrasenyes, wallets, claus i tokens no van al repositori.

Sí que pot anar:

àlies
serveis
entorns
paràmetres no secrets
plantilles
validacions

Entorns reproduïbles

“En la meua màquina funciona”

versió d’Oracle i del client
joc de caràcters i variables NLS_
zona horària
paquets del sistema
rutes lligades a un ordinador: X:\…, \\servidor\…
passos manuals que ningú va escriure

L’entorn també és codi

# Base de dades de proves efímera: la mateixa que arranca la CI.
#   docker compose up -d     # crea l'esquema i carrega el joc de dades
#   docker compose down -v   # no deixa rastre
#
# La contrasenya és local i d'usar i tirar: esta base no conté dades reals.
services:
  oracle:
    image: gvenzl/oracle-free:23-slim-faststart
    environment:
      ORACLE_PASSWORD: local_throwaway
      APP_USER: matricula
      APP_USER_PASSWORD: local_throwaway
      # Fixat perquè el resultat no depenga de la màquina que ho execute.
      TZ: Europe/Madrid
      ORACLE_CHARACTERSET: AL32UTF8
      NLS_DATE_FORMAT: "YYYY-MM-DD HH24:MI:SS"
    ports:
      - "1521:1521"
    volumes:
      - ./01_schema_matricula.sql:/container-entrypoint-initdb.d/01_schema.sql:ro
      - ./02_seed_matricula.sql:/container-entrypoint-initdb.d/02_seed.sql:ro
    healthcheck:
      test: ["CMD", "healthcheck.sh"]
      interval: 10s
      retries: 30

I la màquina que ja tens

El compose val per al que naix nou. Per a un servidor que fa anys que corre:

sudo apt install etckeeper && sudo etckeeper init
sudo etckeeper commit "Estat inicial"

/etc ja és un repositori. A partir d’ahí ningú ha de recordar-se de res:

sudo apt install logrotate
cd /etc && sudo git log --oneline -3

b3293df committing changes in /etc after apt run
e1edf17 Estat inicial
5c38ef2 Initial commit

No ix d’eixa màquina: dins de /etc hi ha shadow i claus privades.

Deu segons, i avant. No és un apartat: només que sàpien que existix, perquè la pregunta natural després del compose és «i el que ja està muntat?».
El commit del mig l’ha fet l’apt tot sol, no una persona: eixe és tot el valor. El ganxo el posa el paquet en instal·lar-se.
Provat en un contenidor net de Debian. Un detall que despista: si el paquet no toca /etc —un htop, per exemple— no hi ha commit, perquè no hi ha res a guardar. No està trencat.
Quan es nota: el dia que una cosa deixa de funcionar després d’una actualització, sudo git diff HEAD~1 en /etc diu quin fitxer va canviar, en compte de buscar-ho de memòria.
L’avís importa: és un repositori local i de root. Ahí dins hi ha shadow i claus privades, o siga que això no es puja a cap servidor, que és justament el que hem dit en l’apartat dels secrets.

Quan està acabada una tasca?

Quan passa la integració contínua.

no quan funciona en el meu portàtil
no quan “a mi em va bé”
qualsevol company pot reproduir el resultat
la mateixa imatge en local i en la CI

Dades de prova

esquema buit amb el DDL de producció
càrrega sintètica menuda
casos límit inclosos expressament
destruir-ho tot en acabar

Mai una còpia de dades reals d’estudiants. I tampoc una còpia completa: per a provar una regla no fan falta totes les dades.

Càrrega sintètica

WHENEVER SQLERROR EXIT SQL.SQLCODE

-- Els scripts d'inici del contenidor s'executen com a SYSDBA contra el CDB,
-- i l'usuari de l'aplicació viu dins del PDB: cal dir a quin contenidor va.
ALTER SESSION SET CONTAINER = FREEPDB1;

-- Càrrega de prova sintètica: noms inventats, volum menut i casos límit.
-- Mai s'han de copiar dades reals d'estudiants a un entorn de proves.
-- La base de dades és efímera, per això el joc de dades no esborra res.

INSERT INTO matricula.estudiant (id, nom, centre) VALUES (1, 'Aitana Ferrer Bonet', 'FIS');
INSERT INTO matricula.estudiant (id, nom, centre) VALUES (2, 'Joan Marí Escrivà', 'FIS');
INSERT INTO matricula.estudiant (id, nom, centre) VALUES (3, 'Neus Bellver Tormo', 'ETSE');

-- Cas normal: cada estudiant, una franja distinta.
-- TO_DATE explícit i no la cadena a seques: així la càrrega no depén del
-- NLS_DATE_FORMAT de qui l'execute i dona el mateix resultat.
INSERT INTO matricula.centre_franja VALUES
  (1, 'FIS', 'G1100', TO_DATE('2026-09-01 09:00', 'YYYY-MM-DD HH24:MI'));
INSERT INTO matricula.centre_franja VALUES
  (2, 'FIS', 'G1100', TO_DATE('2026-09-01 09:30', 'YYYY-MM-DD HH24:MI'));
INSERT INTO matricula.centre_franja VALUES
  (3, 'ETSE', 'G1400', TO_DATE('2026-09-01 09:00', 'YYYY-MM-DD HH24:MI'));

COMMIT;

Pensar les condicions de prova

De què depén realment este procés?

quines taules necessita
quines dades mínimes fan que el cas tinga sentit
quins casos límit hem de cobrir
què hauria de passar si les dades són incorrectes

El registre l’escriu la màquina

A mà, el registre es fa després i el fa una persona cansada:

es copia la comanda al tiquet
s’apega un tros d’eixida
s’anota l’hora aproximada

Automatitzat, el registre és un subproducte: comanda exacta, commit, hora real, eixida completa, resultat.

`commit=a183fe2`

A les 08:00 es detecta que la càrrega de la nit ha deixat dades incorrectes. El log de les 03:00 diu commit=a183fe2.

git show a183fe2
git log --oneline a183fe2..HEAD

Quin codi va córrer, qui el va escriure, per què, i què s’ha tocat després.

“Això funcionava i ara no”

I ningú ha tocat res.

SYSDATE dins de la prova
còpia de producció que canvia cada dia
NLS_, zona horària
ordre de files sense ORDER BY
estat d’execucions anteriors

Fixar la data

-- Caduca sola
WHERE data_inici <= SYSDATE

-- Reproduïble
WHERE data_inici <= TO_DATE('&&data_referencia', 'YYYY-MM-DD')

Amb la data com a paràmetre, el canvi d’any s’assaja en juliol.

Assajar la matrícula

Amb base efímera i dades sintètiques, el procés es pot executar tantes vegades com faça falta:

cada canvi es valida contra el mateix joc de proves
una regressió es detecta el dia que s’introdueix
no cal reservar cap entorn compartit
el dia de la matrícula és una execució més

☕

Pausa

Tornem a les 12:55

Integració contínua

D’on ve el nom. «Integració» no és decoració: era una fase del projecte.

cadascú treballava pel seu costat setmanes o mesos
al final algú havia d’ajuntar-ho tot i fer que compilara i funcionara junt
ningú sabia quant duraria, i el dia de la demostració era una loteria
en anglés li deien «integration hell»
ací va la batalleta: molts dels que programen ho han patit i ho reconeixeran

La idea, tan simple que costa creure que faça falta dir-la:

si una cosa fa mal, fes-la més sovint
integrant cada dia, cada integració és menuda i cap sorpresa és gran
el nom és literal: fer contínuament el que abans es feia una vegada al final

Dates, si es volen:

1991 — Grady Booch usa el terme
finals dels 90 — Extreme Programming (Kent Beck)
2000 — l’article de Martin Fowler
2001 — CruiseControl, la primera ferramenta popular. No Jenkins
2005 — Hudson, la que es va estendre de veres
2011 — es rebateja Jenkins per una disputa de marca amb Oracle, que havia comprat Sun
2016 — Bitbucket Pipelines, el que usem ací

El pont cap a ells, que és el que importa:

no fem branques de sis mesos: la nostra integració no és ajuntar codi de deu persones
és «este script encara funciona contra la base de dades?»
si només es contesta el dia que s’executa de veres, mateix risc en el pitjor moment

Què pot comprovar una pipeline?

secrets accidentals
DELETE sense WHERE
GRANT DBA
scripts sense WHENEVER SQLERROR
errors de Bash
estructura del repositori
documentació mínima
validacions sobre Oracle de proves

Una validació de negoci

-- Ha de retornar zero files si no hi ha cites duplicades.

SELECT centre,
       titulacion,
       franja,
       COUNT(*) AS repetitions
FROM matricula.centre_franja
GROUP BY centre, titulacion, franja
HAVING COUNT(*) > 1;

La pipeline més menuda

# Comprova que tot el Python del repositori compila: no és
# cap prova, però atrapa l'error d'edició que arriba a
# producció a les 3 de la matinada.
# Es pot posar el primer dia, sense proves i sense entorn.
image: python:3-slim

pipelines:
  default:
    - step:
        name: El Python compila
        max-time: 5
        script:
          # compileall torna un codi distint de zero si un
          # fitxer té un error de sintaxi, i això ja posa la
          # pipeline en roig. No fa falta res més.
          - python -m compileall -q .

Cap prova, cap entorn. Un error de sintaxi ja no arriba a producció.

Exemple de pipeline

commit
  ↓
detecció de secrets
  ↓
validació d'estructura
  ↓
anàlisi estàtica
  ↓
execució en proves
  ↓
informe

Abans de pujar

pip install pre-commit
pre-commit install        # una vegada per repositori

A partir d’ahí, cada git commit passa les regles en la teua màquina.

segons, en compte d’esperar la pipeline
no és un control: --no-verify se’l salta
la CI és la que talla; el hook és la comoditat

Tres nivells

	Què vol dir	Qui ho decideix
Integració contínua	cada canvi es valida	ningú, passa sempre
Entrega contínua	queda llest per a desplegar	una persona
Desplegament continu	es publica sol	ningú, passa sempre

Per a publicar sol fan falta

una validació de fiar
un desplegament reproduïble
tornar arrere barat

Si la pipeline es posa verda amb coses trencades, publicar sol només serveix per a difondre errors més ràpid.

Si tornar arrere no és fàcil, ràpid i segur, la gent té por d’anar cap avant.

On sí i on no

Documentació, informes, entorns de proves: desplegament continu.

Processos amb dades reals: entrega contínua i botó humà.

L’objectiu no és desplegar sol, és que quan es decidisca desplegar no faça falta cap passa manual.

Estes diapositives

push a main
     ↓
Bitbucket Pipelines
     ↓
[1] comprovacions estàtiques               ← segons; si falla, s'acaba ací
     ↓
[2] construir en un contenidor Debian net  ← si falla, s'acaba ací
     ↓
[3] empaquetar el web en un zip           ← artefacte descarregable
     ↓
web publicat

Ningú “puja les transparències”.

Un node Oracle des de zero

# Assaig de construcció d'un node Oracle des de zero. No prova que la
# instal·lació siga correcta: prova que el procediment escrit està complet.
pipelines:
  custom:                                  # s'engega a mà, no per commit
    node-oracle-des-de-zero:
      - step:
          runs-on: [self.hosted, linux]    # cal un runner que puga crear VM
          script:
            - IP=$(provisio/vm.sh create "assaig-$BITBUCKET_BUILD_NUMBER")
            - ssh oracle@$IP 'sudo provisio/00-preparar-so.sh'
            # La mateixa passa, una segona vegada: si no és idempotent, el
            # procediment no es pot repetir i encara no val com a document.
            - ssh oracle@$IP 'sudo provisio/00-preparar-so.sh'
            - ssh oracle@$IP 'provisio/10-comprovacions-previes.sh'  # cluvfy
            - ssh oracle@$IP 'provisio/20-instalar.sh'   # runInstaller -silent
            - ssh oracle@$IP 'provisio/30-fum.sh'        # la base respon?
          after-script:                    # s'executa també si ha fallat
            - provisio/vm.sh destroy "assaig-$BITBUCKET_BUILD_NUMBER"

De les diapositives que es publiquen soles a un node sencer: el mecanisme és el mateix.

Esta diapositiva no és una proposta per a demà: és per a que vegen el sostre. Passar de «publiquem un web» a «construïm una màquina» no canvia res del que hem vist.
El que prova no és que la instal·lació siga correcta: és que el procediment escrit està complet. Si s’atura, acabem de trobar la passa que vivia en el cap d’algú.
La passa repetida és la millor línia del fitxer: si no és idempotent, el procediment no es pot repetir.
Si pregunten: els runners del núvol no poden crear màquines virtuals; fa falta un de propi amb accés a l’hipervisor. I els mitjans d’Oracle no van al repositori, ni per mida ni per llicència.
I la trampa que cal dir abans que la diguen ells: una VM no prova un RAC. Valida el node i la preparació del sistema, no l’emmagatzematge compartit ni l’interconnexió.

Practiquem: exercici 5

Provocar una fallada de la pipeline i corregir-la.

Idees: una cadena que parega una contrasenya, un DELETE sense WHERE, un marcador de conflicte oblidat.

Enunciat: el document Exercicis del material del curs

Exercici complet

Flux de pràctica

Crear branca
Modificar SQL
Actualitzar documentació
Fer commit
Publicar branca
Obrir pull request
Veure fallada de CI
Corregir
Revisar
Resoldre un conflicte, si n’hi ha
Fusionar

Per on començar

Un repositori nou d’operació Oracle

No migrar un procés que ja funciona, sinó crear un repositori nou per al que es faça d’ara endavant:

Tot script operatiu nou naix versionat, revisable i amb comprovacions.

comprovacions de tablespaces, sessions, objectes invàlids
usuaris, rols, perfils i grants
jobs de DBMS_SCHEDULER, paràmetres, wrappers
plantilles de configuració i validacions

Cada operació repetible, amb

un fitxer identificable
un motiu o tiquet
una revisió
una comprovació prèvia
una comprovació posterior
una manera de tornar arrere documentada

Dos repositoris, no un calaix

Operació Oracle compartida: administració, comprovació, configuració, manteniment
Cada projecte o procés: DDL, PL/SQL, migracions, dades mestres, validacions

El primer pilot

Crear un repositori nou de scripts i configuració Oracle i fer que el pròxim script operatiu nasca versionat.

comprovació de tablespaces
validació d’objectes invàlids
alta d’un usuari de proves
definició d’un job sintètic
canvi de configuració en un entorn descartable

Adopció gradual

els scripts nous naixen en Git
els canvis delicats es revisen abans d’executar
els processos repetits incorporen comprovacions
els objectes antics s’exporten quan cal tocar-los
de l’execució manual a l’entrega controlada, poc a poc

Tancament

Què sabem fer ara

versionar scripts i llegir l’historial d’un canvi
veure exactament què ha tocat un company, i per què
treballar en branques i revisar-se amb pull requests
resoldre un conflicte senzill i recuperar una versió anterior
muntar un entorn de proves efímer i validar-hi SQL automàticament
entendre què comprova una pipeline i per què es posa roja o verda
fer que un script operatiu nou naixca versionat

Per si ho pregunten: `git reflog`

git reflog

6083d59 HEAD@{0}: merge lateral
36faf91 HEAD@{1}: checkout: moving from lateral to main
d4fa12d HEAD@{2}: commit: C

No és l’historial: és on ha estat HEAD en els teus últims moviments.

Si creus que has perdut un commit —un reset --hard, una branca esborrada—, ací està.

És l’única cosa que salva algú que creu que ha perdut faena.
La diferència amb git log: el log conta la història del projecte; el reflog conta el que has fet tu en este clon. Per això hi ix fins i tot un checkout, que no és cap commit.
Es recupera amb git switch -c recuperada HEAD@{2} o un reset a eixe punt.
És local i temporal: no es comparteix i caduca. Per defecte, 90 dies les entrades accessibles (gc.reflogExpire) i 30 dies les inaccessibles (gc.reflogExpireUnreachable), que són justament les que queden després d’un reset --hard. I només s’aplica quan corre git gc.
És temps, no rotació: no es perd per fer moltes coses, es perd per deixar passar els dies.
Com dir-ho: si algú diu «he perdut un commit», la resposta és esta. Val la pena que sàpien que existix encara que no la useu hui.

Per si ho pregunten: etiquetes

git tag -a v2026.09 -m "Versió desplegada en la matrícula de setembre"
git push --tags
git show v2026.09

Una etiqueta és un nom fix per a un commit. A diferència d’una branca, no es mou.

Útil per a marcar què es va executar en una campanya: git diff v2026.09..v2027.01.

Per si ho pregunten: `cherry-pick`

git cherry-pick a183fe2

Agafa un sol commit d’una altra branca i l’aplica ací.

útil per a portar un arreglament urgent a una branca de manteniment
crea un commit nou, amb hash distint: el mateix canvi existix dues vegades
si acabes fent-ne molts, el que volies era un merge

Per si ho pregunten: per què no `rebase` sempre?

«Si deixa l’historial net, per què no tancar també la pull request amb rebase?»

Es pot. La regla «mai en branca compartida» no valia ací: la branca ja està acabada i s’esborra.

	commit de fusió	squash	rebase
Historial	bifurcat	lineal	lineal
Commits nous en `main`	1	1	un per commit de la branca
Els ha provat la CI	sí	sí	només l’últim
Revertir-ho tot	`revert -m 1`	un `revert`	un per commit
Es veu què anava junt	sí	sí	només en la pull request

Es tria una vegada i es configura en Bitbucket. No és una decisió del dia a dia.

És la pregunta natural després de la recomanació: «si el rebase és millor, per què no sempre?».
No és la mateixa decisió que la de la diapositiva de la recomanació: allà era integrar main en la teua branca, a mà i cada dia; ací és el botó que tanca la pull request, una vegada i quan la branca ja no la té ningú.
La pega del rebase al tancar no és la seguretat, és que A' i B' són estats que no ha construït mai ningú: un git bisect pot parar en un commit que ni tan sols arranca.
A més, els conflictes els menja qui obri la pull request, i commit a commit.
squash és el punt mig habitual: historial lineal, un commit per pull request, revert d’una línia. El preu és perdre els commits intermedis, que en una branca curta no es troben a faltar.
On es tria, per si ho pregunten: Repository settings → Merge strategies, amb tres opcions (merge commit, squash i fast-forward) i una per defecte. Amb branch restrictions es pot fixar per branca.
Si algú diu «a mi se m’ajunten tots els commits en un», no és cosa del seu Git: és que el repositori té squash com a estratègia per defecte.
Com dir-ho: «es pot, i molta gent ho fa; però eixa la trieu una vegada per repositori, no cada matí».

Per si ho pregunten: i des de Bitbucket?

«Tot això no es configura des de la web, sense tocar la consola?»

Una part sí, i convé saber-ho:

editor de bitbucket-pipelines.yml en el navegador, amb validació i commit directe
variables i secrets: Repository settings → Repository variables
entorns i aprovacions: Deployments
executors propis: Repository settings → Runners

El que no hi ha és un constructor de caixes i fletxes: la pipeline sempre és el fitxer YAML del repositori.

Per a seguir

Git: git-scm.com/doc i el llibre Pro Git (lliure)
Bitbucket Pipelines: la documentació del propi Bitbucket
Detecció de secrets: gitleaks
Linters de SQL: sqlfluff, sqlcheck
Proves de PL/SQL: utPLSQL

Git i CI per a processos Oracle

Objectiu

Què volem aconseguir?

Com anirà el matí

On està tot

Què no us demane

Si ja useu Git

Problema

On és la versió correcta?

Un patró habitual

Un sol fitxer

De procediments manuals a canvis traçables

Git essencial

Aconseguir el repositori

Què tinc ara mateix?

Les tres zones

El cicle mínim

Què aporta un commit?

El commit, per dins

Què ha canviat un company?

Funcionava fa una setmana

Mirar, restaurar, revertir

El repositori remot

Les tres que es confonen

M’han interromput

Reescriure l’historial

Què forma realment el projecte

El missatge diu per què

Dos canvis en un mateix fitxer

Practiquem: exercici 1

Branques i revisió

L’historial és una cadena

Una branca és un punter nou

Els teus commits van a la teua branca

Mentrestant, main avança

Fusionar

Moure’s entre branques

Dues maneres d’integrar

Opció A: git merge main

Opció B: git rebase main

Quina trie?

La recomanació per a nosaltres

I això no cal dibuixar-ho

Pull request

No és control personal

Dos toquen la mateixa línia

Practiquem: exercicis 2, 3 i 3b

SQL i Oracle

Què podem versionar?

Què podem versionar?

Què no hi va mai

Si un secret ja ha entrat

Quants repositoris?

Criteris d’organització

La mida no sol ser el criteri

Exemple: alta d’un usuari

create_user.sql

Important

Entorns reproduïbles

“En la meua màquina funciona”

L’entorn també és codi

I la màquina que ja tens

Quan està acabada una tasca?

Dades de prova

Càrrega sintètica

Pensar les condicions de prova

El registre l’escriu la màquina

commit=a183fe2

“Això funcionava i ara no”

Fixar la data

Assajar la matrícula

Integració contínua

Què pot comprovar una pipeline?

Una validació de negoci

La pipeline més menuda

Exemple de pipeline

Abans de pujar

Tres nivells

Per a publicar sol fan falta

On sí i on no

Opció A: `git merge main`

Opció B: `git rebase main`

`create_user.sql`

`commit=a183fe2`

Per si ho pregunten: `git reflog`

Per si ho pregunten: `cherry-pick`

Per si ho pregunten: per què no `rebase` sempre?