Billig, hvordan utvikle

Billig utvikles i git, med en enkel arbeidsflyt. Les også Billig kode for forklaring på kodestil og lignende.

Hvordan opprette personlig utviklingstre

cassarossa:~> git clone /home/cassarossa/itk/felles/git/billig
Cloning into billig...
done.

Ting som må gjøres for å få egen billig-instans til å funke

Følg oppskriften for medlemsdb2, hvordan utvikle. Bytt ut mdb2 med billig overalt. Deretter:

Kok noen andres config.local.pm fil. Se til at den har riktige rettigheter.

cp /home/cassarossa/itk/<enannenbruker>/dev/billig/include/config.local.pm ~/dev/billig/include/config.local.pm
sudo chown <brukernavn>:billig-web ~/dev/billig/include/config.local.pm
Bytt ut navnet til brukeren du har kokt fra med ditt overalt der det virker naturlig i denne filen.

Lag en mappe som heter cache i templatesmappen i billig-kopien din. Endre deretter eier og gruppe på denne mappen til billig-web.

mkdir ~/dev/billig/templates/cache
sudo chown billig-web:billig-web ~/dev/billig/templates/cache

Oppsett for sending av commit-eposter

Det er veldig greit for andre å følge med på utvikling som skjer ved at man sender epost når man koder noe nytt. Dette kan gjøres veldig greit ved å legge inn en epost-hook i git-configen din. (Det er allerede en sentral hook for når du pusher til stable.)

cassarossa:~> cd billig
cassarossa:~/billig> ln -s /home/cassarossa/itk/felles/git/post-commit-email .git/hooks/post-commit
cassarossa:~/billig> git config –local hooks.mailinglist itk-commits-billig@samfundet.no
cassarossa:~/billig> echo billig.$USER > .git/description

Det vil da bli sendt en epost hver du commiter noe til det aktuelle arkivet.

Kjøring av enhetstester

Billig har ikke voldsomt mange enhetstester ennå, men det er greit å sjekke at de som er der, faktisk passerer:

cirkus:~> cd billig/test 
cirkus:~/billig/test> ./do-tests.sh 

do-tests.sh tar opp en helt ren Postgres-instans for deg, laster den med Billig-skjema, kjører alle testene og gir deg coverage-rapport.

Det er foreløpig ikke krav om enhetstester av ny kode, men skriv dem gjerne om du ønsker.

Push til stable

# Commit endringene dine

$ git commit -a -m "Mine endringer"

Herfra har du to alternativer. Enten kan du pushe dem rett ut i master, eller så kan du gå gjennom review. For å pushe direkte:

# Merge inn eventuelle endringer fra stable.

$ git pull

# Om alt fungerer etter merge, merge ditt tre inn i stable

$ git push

Alternativet er å gå gjennom review i et system som heter Gerrit. Review er helt frivillig, men kan være nyttig om du er usikker på noe eller bare vil ha et annet par øyne til å gå gjennom koden din. Review-prosessen kan være litt skummel første gang, og du må regne med å gå flere runder med revieweren din i en prosess som ofte kan oppfattes som en mur av kritikk. Til gjengjeld er det en glimrende måte å lære på. (Selv om du ikke går gjennom review, kommer det til å gå ut en epost til epostlisten; ikke bli overrasket om du får epost på denne.) Prosessen er ganske grei:

# Send inn koden for review. En mer erfaren utvikler kommer til å ta tak i
# koden din innen kort tid (evt. kan du sende URLen din direkte til en person
# du ønsker skal gjøre review).

$ git review

# Når du har fått kommentarer og vil gjøre endringer:

$ git commit -a --amend
$ git review

Utrulling på cirkus

Utrulling av ny kode på cirkus består i all enkelhet av å sjekke ut den siste koden fra det sentrale git-treet på rett sted og HUP-e apache for å få mod_perl til å laste koden på nytt. Apache kjører som brukere billig-web for vhosten billig.samfundet.no, med hjemmeområde der koden ligger, på cirkus:/var/www/samfundet.no/billig. Utrulling er derfor slik:

cirkus:~# su - billig-httpd
billig-web@cirkus:~ git pull
cirkus:~# /etc/init.d/apache2 reload

Utrulling på okkupasjon

Merk at kun personer med bruker på okkupasjon kan rulle ut ny kode på den. Billig sikkerhetspolicy skal selvfølgelig til enhver tid følges.

Utrulling av ny kode til okkupasjon består i all enkelhet av å sjekke ut den siste koden fra det sentrale git-treet. Ny kode må først pushes til dette, og så sjekkes ut.

Før ny kode rulles ut bør det vurderes om billettsalget bør slås av. For samfundet.no gjøres dette i filen /var/www/samfundet.no/www/application/config.ini, og for uka.no gjøres det i /var/www/uka.no/www/ukeweb-prod/ukeweb/settings/billig_local.py.

Utsjekking gjøres slik, fra et skall på okkupasjon:

sudo su - billettsalg
cd /var/www/samfundet.no/billettsalg
git pull
exit
sudo /etc/init.d/apache2 restart

Hvordan koble til okkupasjon

okkupasjon snakker ikke med verden, kun med cirkus. Det er imidlertid ikke nødvendig (eller ønskelig) å faktisk gi cirkus okkupasjon-passordet ditt; bruk i stedet en kommando ala.

ssh -o ProxyCommand='ssh cirkus.samfundet.no nc %h %p' okkupasjon

Da vil du først bli bedt om å skrive cirkus-passordet ditt (om du ikke har nøkler eller Kerberos-billett) og så okkupasjon-passordet ditt.

Eller, i .ssh/config på maskinen du ssh-er fra:

Host okkupasjon
    Hostname okkupasjon.samfundet.no
    ProxyCommand ssh cirkus.samfundet.no nc %h %p

og så kan du gjøre rett og slett ssh okkupasjon hver gang.

Utvikling av okkupasjon-backend

Jfr. Billig sikkerhetspolicy skal det aldri utvikles direkte på okkupasjon. I stedet anbefales det at du setter opp et testmiljø som følger:

  1. Opprett din egen testdatabase ved å klone mdb2-databasen.
  2. Sjekk ut ditt eget Billig-tre som vanlig.
  3. Opprett en ny test-vhost. Denne skal være satt opp som en vanlig Billig-vhost, unntatt at den skal bruke web-confined i stedet for web.
  4. Om du trenger en test-frontend, klon samfundet.no-frontenden med cp -a og sett opp en egen vhost. Pek test-frontenden din til test-backenden, og pek test-backenden på test-frontenden ($dave_ok_url m.m. i config.local.pm).
  5. Pek test-backenden på din egen database (config.local.pm). Husk å bruke en fake HMAC-nøkkel.
  6. Pek test-backenden på PayEx-testkontoen vår, og pek PayEx-testkontoen vår til din egen testbackend.

NB! Bruk aldri den vanlige databasen (mdb2) til å teste okkupasjon. Pek aldri produksjonsfrontends til testbackends eller motsatt.

Legge til ny bruker på okkupasjon

Opprett en vanlig bruker på okkupasjon.

$ sudo adduser <brukernavn> 

SSH-nøkkel genereres på en datamaskin som kun brukes av personen det lages bruker til. Filen med privatnøkkelen skal som hovedregel ligge på en kryptert disk. Nøkler på ukrypterte disker skal være passordbeskyttet (og dermed kryptert). De eneste nøkkeltypene tillatt er RSA og Ed25519. Nygenererte nøkler skal fortrinnsvis være Ed25519. Eksisterende RSA-nøkler tillates brukt, så lenge de har minst 2048 bits nøkkellengde. Nygenererte RSA-nøkler må ha minst 4096 bits lengde.

Generering av nye nøkler:

$ ssh-keygen -t  ed25519 -f okkupasjon

Public-delen legges på okkupasjon i ~/.ssh/authorized_keys, da i den nye brukerens hjemmeområde. Pass på att .ssh har permissions 700, authorized_keys har 644, og begge er eid av den nye brukeren.

Den nye brukeren legges til i sudoers.

$ sudo visudo 

Se på formatet på brukerene som ligger i filen fra før og gjør det samme med den nye brukeren.

Testing på samfundet.no

www-beta.samfundet.no er for testing mot okkupajson. Snakk med MG-web for tilganger her.

Lenker: Start, billig, billig v1, hvordan utvikle

Mail: itk@samfundet.no | Telefon: 992 15 925 | Sist endret: 2018-10-26 11:08 | Revisjon: 47 (historie, blame) | Totalt: 1469 kB | Rediger