Adrian Lienhard wrote:
actually, about a year or two ago we used a web interface to
Monticello or DVS, the ancestor of Monticello, to load the new code.
We also had (and still have one) images running headless. But
sometimes it's really useful to have the ui remotely, e.g., to
evaluate some initialization scripts or to flush the seaside cache.
You could also do this over the web of course, its just more
convenient. Especially when there were problems it was very useful to
have VNC, to look at the process browser, or even to do a alt-.
Though, this should, hopefully, not be very often needed ;-)
Most of the time on a real "deployed" app you will not need VNC.
However, depending on your customer's needs you might deploy earlier
than you like, especially if they don't mind a few hiccups. In these
cases having VNC (and the bandwidth to support it) are really a must.
I'm mostly using Seaside in this situation right now. My biggest
customer is experimenting with several small apps. I develop locally
but don't have the time to develop "upgrade scripts" so when I need to
make a change I suffer through VNC.
The roll over method that Andrew and Avi discussed would be the way to
go for a production app. I'm just not there yet and I am probably not
the only one working Seaside into the nooks and crannies where we don't
have a solid $$ investment in the work so time has to be kept to a
minimum. I suspect that I'm not in the minority here. I don't collect
a dime for any work in Seaside. That day will come and at that time
I'll invest in better infrastructure.
So basically,
Develop locally.
Publish to MC repository.
Update server from the MC repository.
...then debug. Especially if you're running against GOODS. Honestly,
in my type of Seaside work (again, "proof of concept" apps) you don't
have time to work methodically along writing migration scripts for your
DB as you refactor your classes. I deploy early and often and have a
customer that is willing to endure a 1 or 2 hour hiccup while I fix
things after the "update server from the MC repository". Plus, I can
always "roll back" the previous version if the migration didn't go
well...BACK UP YOUR IMAGE AND DB BEFORE YOU UPDATE!!!!! :-) :-) :-)
Jimmie Houchin wrote...
I have not developed a website, so have no experience. I wasn't sure
how it was normally done in Squeak/Seaside. I couldn't imagine
actively developing with the deployed image machine. But I wasn't
quite sure how one went about adding new features and items to a
deployed website that you don't have physical access to.
Yes, you don't want your customers to suffer through "active
development" on a live app. Still, though, there is a difference
between developing and debugging a deployed app. I release almost once
a week which means every week I spend some time on VNC dealing with
problems on the server. It drives me nuts but I'll live with it rather
than go back to JSP's.
My server currently is at my home on my LAN. I wanted to learn
somewhat how these issues were handled,while I can explore and
experiment with the different processes while I currently do have
physical access. Once I deploy access is about 80 miles, 128 km, or
about 2 hours away. Not horrible, but also not horribly convenient. :)
In my opinion, unless you have a serious app you won't have the time to
invest in the procedures needed to make deployment seamless. If you're
just muddling your way along, like me, you'll want to have VNC access
that you can live with. When I finally collect a check from something
in Seaside I'll change my tune. Again, I don't think that I'm alone.
David
--
C. David Shaffer
http://www.cs.westminster.edu/~shaffer
http://www.shaffer-consulting.com
|
