Kontinuerlig Integration System for en Python Codebase

stemmer
51

Jeg begynner å jobbe på et hobbyprosjekt med en Python kodebase, og jeg ønsker å sette opp noen form for kontinuerlig integrasjon (dvs. kjører et batteri av test tilfeller hver gang innsjekkings er gjort og sende maser e-post til ansvarlig personer når testene ikke bestått) ligner Cruise eller TeamCity .

Jeg innser at jeg kunne gjøre dette med kroker i de fleste VCSes , men det krever at testene kjøres på samme maskin som versjonskontroll server, som ikke er like elegant som jeg ønsker. Er det noen som har noen forslag til en liten, brukervennlig, open-source kontinuerlig integrasjon system som egner seg for en Python kodebase?

Publisert på 02/08/2008 klokken 18:43
kilden bruker
På andre språk...                            


7 svar

stemmer
28

En mulighet er Hudson. Det er skrevet i Java, men det er integrasjon med Python prosjekter:

Hudson omfatter Python

Jeg har aldri prøvd det selv, men.

( Update , september 2011: Etter et varemerke tvist Hudson har blitt omdøpt til Jenkins .)

Svarte 02/08/2008 kl. 18:56
kilden bruker

stemmer
27

Vi kjører Buildbot - Trac på jobben. Jeg har ikke brukt det for mye siden min kodebasen er ikke en del av utgivelsessyklus ennå. Men vi kjøre testene på ulike miljøer (OSX / Linux / Win) og sender e-post - og det er skrevet i Python.

Svarte 02/08/2008 kl. 19:06
kilden bruker

stemmer
18

Sekund Buildbot - Trac integrering. Du finner mer informasjon om integrering på Buildbot nettstedet . På min forrige jobb, skrev vi og brukte plugin de nevner (tracbb). Hva plugin gjør er å skrive om alle de Buildbot nettadressene slik at du kan bruke Buildbot innenfra Trac. ( Http://example.com/tracbb ).

Det virkelig fine ting om Buildbot er at konfigurasjonen er skrevet i Python. Du kan integrere din egen Python-kode direkte til konfigurasjonen. Det er også svært enkelt å skrive dine egne BuildSteps å utføre bestemte oppgaver.

Vi brukte BuildSteps å få kilde fra SVN, trekke avhengigheter, publisere testresultater til WebDAV, etcetera.

Jeg skrev en X10-grensesnitt, slik at vi kan sende signaler med bygge resultater. Når bygge mislyktes, vi byttet på en rød lava lampe. Når bygge lyktes, en grønn lava lampe slått på. Gode ​​tider :-)

Svarte 03/08/2008 kl. 12:09
kilden bruker

stemmer
17

Vi bruker både Buildbot og Hudson for Jython utvikling. Begge er nyttig, men har forskjellige styrker og svakheter.

Buildbot konfigurasjon er ren Python og ganske enkelt når du først får taket på det (se på epydoc generert API docs for den mest oppdaterte informasjon). Buildbot gjør det lettere å definere ikke-testing oppgaver og fordele testere. Men egentlig har det ingen begrep om individuelle tester, bare tekstlig, HTML og sammendrag utgang, så hvis du ønsker å ha multi-level søkbar test produksjon og så videre må du bygge den selv, eller bare bruke Hudson.

Hudson har veldig bra støtte for boring ned fra samlede resultater i testsuiter og individuelle tester; Det er også stor for å sammenligne testutgang mellom bygger, men distribuert (master / slave) ting er relativt mer komplisert fordi du trenger en Java-miljø på slavene også; også, er Hudson mindre tolerante overfor ustabil nettverksforbindelser mellom master og slaver.

Så, for å få fordelene av både verktøy, kjører vi en enkelt forekomst av Hudson, som fanger de vanlige test feil, så vi gjør multi-plattform regresjon med Buildbot.

Her er våre tilfeller:

Svarte 15/09/2008 kl. 00:11
kilden bruker

stemmer
7

Vi bruker Bitten wich er integrert med trac. Og det er python basert.

Svarte 16/09/2008 kl. 16:51
kilden bruker

stemmer
6

TeamCity har noen Python integrasjon .

Men TeamCity er:

  • ikke åpen kildekode
  • er ikke lite, men heller funksjonsrikt
  • er fri for små-mellom lag.
Svarte 22/09/2008 kl. 21:18
kilden bruker

stemmer
5

Jeg har veldig gode erfaringer med Travis-CI for mindre kodebaser. De viktigste fordelene er:

  • oppsettet er gjort på mindre enn et halvt skjermen på config fil
  • du kan gjøre din egen installasjon eller bare bruke gratis hosted versjon
  • semi-automatisk oppsett for GitHub depoter
  • ikke hensyn trengs på nettstedet; Logg inn via GitHub

Noen begrensninger:

  • Python er ikke støttet som en førsteklasses språk (som i skrivende stund, men du kan bruke pip og apt-get til å installere python avhengigheter, se denne opplæringen )

  • koden må ligge på GitHub (i hvert fall når du bruker den offisielle versjonen)

Svarte 02/02/2012 kl. 21:42
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more