Controllo versione per Smalltalk/Seaside?

Question

Sono principalmente uno sviluppatore Java EE. Mi è stato chiesto di esplorare la possibilità di utilizzare Smalltalk/Seaside in un prossimo progetto web. Come puoi immaginare, questo ha portato a molte domande interessanti.

Come fa un team di sviluppatori a implementare il controllo delle versioni del software e della revisione con Smalltalk/Seaside. Puoi usare Subversion o Git?

Da quello che ho capito, Smalltalk utilizza un'immagine anziché salvare ogni classe nel proprio file. In che modo ciò influisce sulla capacità di gestire le revisioni del codice sorgente, in particolare attraverso un team?

Mille grazie per qualsiasi suggerimento che possiate fornire!

Answer 1

installazione per Pharo (e Gemstone)

Ogni sviluppatore lavora a sua immagine. Ogni modifica a un metodo che esegue viene salvata localmente nel file delle modifiche. Ciò consente il recupero in caso di arresto anomalo dell'immagine. I commit vengono creati creando un file monticello, con il nome di un pacchetto, il numero di sequenza e il nome dello sviluppatore. Conosce la sua ascendenza. Questo file viene salvato su un server WebDAV. Qui è raccolto da un Jenkins task. Questo esegue i test di unità e integrazione e crea nuove immagini, in modo che gli sviluppatori possano iniziare con un'immagine nuova (almeno) ogni giorno. Ecco alcuni dettagli su merging usando monticello. La composizione del prodotto (struttura del pacchetto) è un altro file di monticello contenente una descrizione di metacello. Questo permette anche di svilupparsi su Pharo e schierare su Gemstone. Di tanto in tanto è necessario aggiungere migrazioni di classe.

per le dipendenze non Smalltalk e lo sviluppo, di test di accettazione e le differenze di produzione, aggiungere la creazione di immagini VirtualBox utilizzando vagrant, chef-solo (o puppet, speriamo presto Coral), veewee. Sono ovviamente versione gestita usando git.

Oltre a utilizzare strumenti di controllo del codice di qualità statici (smallLint, controlla anche le differenze tra i dialetti Smalltalk), aggiungere Moose e creare il proprio dipendente dal contesto, visualizzazioni dinamiche del progetto (humane assessment)

Nel VisualWorks Smalltalk lo sviluppatore locale usa STORE con un database relazionale (ad esempio PostgreSQL) per memorizzare commit locali. Il codice è organizzato in pacchetti di pacchetti, con namespace. Uno script di replica viene utilizzato per copiare le versioni locali da e verso un database centrale. Da lì il flusso è lo stesso del setup Pharo.

[aggiornamento] In Esug2012, Dale Henrichs ha presentato il lavoro per rendere possibile l'utilizzo di git e github per gestire il codice smalltalk per più dialetti. Fondamentalmente, è stata definita una struttura di file (Cypress per Ambra, Pietra preziosa, Pharo, Squeak, VisualAge, STIG per VisualWorks) per memorizzare i metodi smalltalk nelle directory. Questo è attualmente finalizzato più allo scambio di codice tra dialetti che a sostituzione del SCM nativo.

Answer 2

Smalltalk dispone di un proprio sistema di impacchettamento/controllo delle versioni, in cui i pacchetti del codice sorgente sono sotto controllo, suddivisi, uniti, ecc. Quali dialetti Smalltalk si prevede di utilizzare? Pharo ha Monticello e Metacello, Squeak ha Monticello, VisualWorks ha STORE.

Answer 3

VA Smalltalk ha Envy.

Quale mai Smalltalk scegli, penso che ti piacerà molto Seaside.

Answer 4

Risposta breve: non è possibile (per ora) utilizzare Git o Subversion.

Anche risposta breve: non è necessario che :)

risposta Grande: Vedere Stephan spiegazione su come si crea Pharo è di per sé :)) Naturalmente, se siete abituati a file sistemi basati, questo sarà strano in prima istanza, ma una volta che inizierai a lavorare, ti renderai conto che hai tutti gli strumenti necessari per controllare la versione (monticello - questa è la sostituzione di Git/Subversion) e per creare installazioni complesse (metacello - questo è la sostituzione per cose come Maven). Con un po 'di lavoro (come sempre e con qualsiasi piattaforma tu scelga), puoi configurare il tuo server di integrazione continua (jenkins o hudson o qualsiasi altra cosa) e presto lavorerai come in altri ambienti, ma con un grande vantaggio: tu sarà in fase di sviluppo Seaside/Smalltalk: P

Answer 5

Lo sviluppo in Smalltalk è in genere più produttivo, ma è necessario conoscere prima i nuovi strumenti: Monticello/Metacello per il packaging (si pensi a come salvare un pacchetto in un proprio file ZIP con mcz estensione e un proprio numero di versione ogni volta che si commette). Metacello fornisce le informazioni che i pacchetti Monticello si adattano e dovrebbero essere caricati per fornire un'app di lavoro completa (simile a POM in Maven, ma in un file di classe specifico ConfigurationOfXXX dove XXX è il nome dei componenti). Non hai bisogno di strumenti di versioning non di Smalltalk come subversion a meno che tu non voglia gestire risorse esterne come immagini o script di database.

Guarda anche l'integrazione di Hudson/Jenking poiché ciò ti aiuterà anche ad automatizzare la costruzione dell'immagine e l'integrazione continua.

Answer 6

Ci sono alcuni strumenti per Svn/Git, ma IMHO è molto meglio andare con il flusso qui e usare Monticello perché Monticello ti offre un'esperienza molto simile a git, ma molto più semplice da usare e molto più integrato con il "modo Smalltalk".

Non hai specificato quale Smalltalk, ma se stai per usare Pharo è sicuramente Monticello (e quando le cose si complicano - Metacello in alto) da usare.

Answer 7

Si può essere interessati anche a Amber.