[Seaside] is this workflow incorrect?
dhenrich at vmware.com
Thu Sep 27 17:08:34 UTC 2012
You might want to checkout some of my recent work with Metacello, Git and GitHub....
The short answer is that it is possible to use git for your development ... storing monticello packages and static files (js, etc.) in git is definitiely doable.
The long answer is that I've been working in Git/GitHub since late January. The FileTree project makes it practical to store Monticello packages on disk and therefore makes it possible to stash your smalltalk code on Git and use Github. I have recently announced a Metacello Preview release (1.0.0-beta.32.3) that adds git/github support to Metacello,.
If you take a look at the amber-skeleton and take a look at the set up instructions for the pharo server, you'll see that I've used git to build the directory structure around the server (in this case Pharo) in addition to all of the source code, scripts and documentation ...
Regarding the duplicate pharo/gemstone testing, I'll just say that a little bit of paranoia goes a long way:) The Pharo and GemStone environments aren't exact copies of one another, so it is just prudent to make sure that things work as well in GemStone as they do in Pharo ... I don't think you'd want to skip the steps, but automating the steps would be a big advantage ... along those lines, TravisCI provides continuation integration support tied to GitHub push/pull requests ... automated builds and tests, that I am using for all of my pharo work ... right now Travis only supplies 32 bit environments, but as soon as a 64 bit environment shows up I will be using Travis for GemStone as well ...
----- Original Message -----
| From: "sergio_101" <sergio.rrd at gmail.com>
| To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
| Sent: Thursday, September 27, 2012 5:44:47 AM
| Subject: [Seaside] is this workflow incorrect?
| i am trying to wrap my head around the development workflow, and i
| want to make sure i am doing this as efficiently as possible.
| can someone comment on this?
| 1. develop away in my local image. this includes all classes,
| components, and tests. this does not include editing static files.
| 2. my static files are served up by a local running version of
| and my resource base is set to point there. at this point, the
| way i can think of keeping these files wrapped up in the project
| by using a file based system (git) to version and deploy static
| 3. pull my project into a local gemstone to make sure there are no
| problems. i am thinking that a more robust test bed would probably
| be good enough here. if my tests all pass in gemstone, i should be
| good to go.
| 4. pull project into deployed gemstone, run tests, and let it rip.
| there are only few things i don't like about this. i am not sure i
| like the idea of having to run a local gemstone and test the app in
| two places (gemstone and pharo). since i am new to this, i would
| imagine i can drop this step at some point.
| i don't like (at all) the idea of running monticello for my seaside
| project, and git for my static files. i am thinking i am doing this
| in a perfect world, i would have monticello somehow (without using
| file libraries) keep track of my css, image, and js files without
| having to
| run two versioning systems.
| i absolutely don't want to serve up static files through seaside, so
| am not sure how to rectify all this.
| how are you guys handling these issues?
| photographer, journalist, visionary
| seaside mailing list
| seaside at lists.squeakfoundation.org
More information about the seaside