Integrazione continua per i compiti degli studenti

Question

Ok, quindi questo potrebbe sembrare un po 'strano ma qui va.

Sto insegnando un laboratorio di strutture dati e algoritmi presso la mia università locale e voglio dare ai miei studenti un'esperienza fluida e divertente. Fino ad ora, ho usato un semplice repository git che ogni studente ha biforcato, e ogni volta che hanno completato un incarico, hanno fatto una richiesta push + pull, vorrei rivedere il loro codice e se tutto andava bene, avrei unito la richiesta pull pronti contro termine. Funziona abbastanza bene, ma voglio fare qualcosa di più interessante.

Il laboratorio viene insegnato in C (nemmeno in C++) (e no, non voglio inserire polemiche sul perché un altro linguaggio sarebbe migliore). Quello che voglio fare è avere qualcosa come una build di Jenkins eseguita su ogni spinta effettuata da un alunno che verifica alcuni test predefiniti per l'attività in corso.

Ad esempio, per la settimana 2, assegnerei loro un compito a casa con le liste. Vorrei scrivere personalmente i test per questo compito e quindi verificare automaticamente che cosa hanno fatto usando quei test.

Quello che ho a disposizione:

• 24/7 in esecuzione della macchina CentOS che posso usare per mettere qualche cosa su (ho Jenkins e Tomcat in esecuzione su di esso atm)
• abbastanza tempo e forza di volontà per cercare di fare la loro esperienza in questo laboratorio vale la pena

++ un bel 'componente aggiuntivo' per tutto questo sarebbe utilizzare qualcosa come sonar come verificatore di codice E controllare il codice duplicato all'interno delle loro filiali (come per vedere se qualcuno ha copiato una risposta da qualcun altro)

Sono sulla strada giusta andando per un server Jenkins, pensando al sonar, ecc? Sono lontano? Non penso che sia impossibile. Potrebbe essere difficile, sì, ma che lo rende divertente ^^

Il 'flusso' che voglio è:

• ogni studente è parte di un'organizzazione git + repo
• Creano un ramo dal padrone locale (imporrò una limitazione come 'usa solo una sottocartella con il tuo nome')
• il ramo principale conterrà i test
• lavoreranno ai compiti sul loro ramo e poi lo spingeranno a Jenkins/Gerrit/qualunque sia
• il ramo verrà in qualche modo testato e se tutti i test passano, sarà unito al master.

Per conto dei miei cari studenti, grazie.

Answer 1

TL; DR: sì, quello che vuoi fare è fattibile, e stai già guardando gli strumenti corretti.

---

Quello che vuoi, appare del tutto fattibile: installare il Git plugin per Jenkins, configurarlo per tenere traccia di ogni rami del pronti contro termine, ed è già possibile lanciare una generazione dopo ogni spinta.

Dato che è possibile eseguire script arbitrari durante una build di Jenkins, è possibile concedere autorizzazioni push all'utente Jenkins e farsene unire e inserire il codice se tutti i test superano.

È inoltre possibile installare un server sonar e chiamarlo tramite lo Sonar plugin e gli studenti riceveranno questo feedback aggiuntivo.

D'altra parte, Gerrit potrebbe essere un po 'eccessivo per quello che stai cercando. O meglio: è uno strumento prezioso, ma credo che non ne abbia bisogno per la prima iterazione.

Mi vengono in mente due tipi di difficoltà:

1. casi Scripting/angolo
2. Se si desidera impedire studente di gioco del sistema

per (1), voglio dire che dovrai implementare le tue regole (ad esempio "costruisci solo la sottocartella che appartiene all'ultimo committer"; "non creare commit di unione sul master"; ...). E è probabile incorrere in problemi tali che:

• non si vuole una nuova Jenkins eseguito su un merge commit solo spinto da un lavoro di Jenkins, in modo da dovrete tenerne conto nel costruire sceneggiatura
• che cosa succede se si desidera consentire diversi Jenkins funzionare allo stesso tempo, e due piste cerca di unire e spingere al tempo stesso

immagino avrete solo bisogno di risolvere questi difetti, come si' Li scoprirò. Basta pensare a creare backups della tua configurazione Jenkins (potresti anche memorizzarli in un repository git ad hoc).

Per (2), voglio dire che potresti voler prendere in considerazione, ad esempio, il caso in cui uno studente cancellerebbe dal repository i test che la sua implementazione non può superare. O il caso dello studente che spingerebbe direttamente sul master.

Credo che si potrebbero aggiungere molti controlli per evitare questo tipo di imbroglio, tuttavia, piuttosto che entrare in un "conflitto tecnologico", immagino che sarebbe più salutare dire semplicemente che ci si fida di loro.