>> I'd like to know the development process of others, from SCM to >> building, deploying and server provisioning. > > I would say the standard approach is: > > - use Monticello with any repo type > - split your code in some big modules, some private, some from public source > - have a single overarching Metacello configuration > - use zeroconf to build images > - optionally use a CI > > Note that zeroconf handlers allow you to build images incrementally (the > image is saved after each build), which is way faster than always starting > from scratch.
I'm good then, I'm doing everything you listed except CI. >> After a year o Pharo development I think I'm ready to embrace a CI >> server (I already use scripts to build images), but I think I will >> move all my repositories to git before. > > These are orthogonal decisions, most CI jobs on the Pharo contribution server > run against StHub. I want git because I want to use BitBucket to store my code :) >> However, my remote server provisioning is still manual, and too >> rudimentary even for my own taste. If I could speed up this, I would >> deliver features faster to my customers. Now everything runs inside a >> two week sprint window. > I am not into provisioning myself, but more automation is always good, though > sometimes setting up and maintaining all these things takes a lot of time as > well. It does take time, and "in theory" it works. I have this printed in my desktop: http://xkcd.com/1319/ :) Wrapping up, I implemented your no-commandline handler solution. I added a few servers to the upstreams of my site nginx configuration like this: upstream seaside { ip_hash; server 127.0.0.1:8080; server 127.0.0.1:8081; server 127.0.0.1:8082; server 127.0.0.1:8083; } upstream apimobile { server 127.0.0.1:8180; server 127.0.0.1:8181; } And added the following to my following supervisord.conf [1] [program:app_webworker] command=/home/trentosur/app/pharo app.image webworker.st 818%(process_num)1d process_name=%(program_name)s_%(process_num)02d ; process_name expr (default %(program_name)s) numprocs=4 directory=/home/trentosur/app autostart=true autorestart=true user=trentosur stopasgroup=true killasgroup=true [program:app_apiworker] command=/home/trentosur/app/pharo app.image apiworker.st 918%(process_num)1d process_name=%(program_name)s_%(process_num)02d ; process_name expr (default %(program_name)s) numprocs=2 directory=/home/trentosur/app autostart=true autorestart=true user=trentosur stopasgroup=true killasgroup=true Then this will spawn a [numproc] number of monitored processes, using the process number (process_num, in terms of pool) as a parameter to the startup script. The good thing here is, IMO, I can add more workers without having to modify anything on the Pharo side, it is... I can delegate this to regular sysadmin :) Best regards, Esteban A. Maringolo [1] http://supervisord.org/
