On 05/01/15 18:21, Nathan Stults wrote:
Are there any best practices around developing services for Zato in a
test driven way? What kind of project structure are you guys using for
your Zato services projects? Ideally our service code would live in a
git repo with branches for dev, staging and test and could be deployed
to the various environments from there and tested using some kind of CI,
but I’m not quite sure where to begin (unfortunately we’re pretty new to
python, so this may be self evident to all but us )
I’m not sure about others but I always test integration services using
A Zato project is simply a directory of Python modules:
Each of the modules contains one or more services.
On test and production, the services are deployed using Jenkins which
simply copies (cp) modules to a hot-deploy directory.
During the development, if I cannot work on a local server - for
instance if there is no VPN and a firewall to remote databases cannot be
opened due to internal policies - I deploy services remotely from
But if I can work on localhost and a client’s repo layout allows it, I
simply clone/check out code directly into a server’s pickup-dir. That
way, after setting server.conf’s misc.delete_after_pick_up to True, I
have deploy-on-save in IDE.
So my setup is pretty straightforward - people tend to use
Jenkins/Chef/Ansible to automate things or invoke API services for
in advanced cases but I haven’t actually done a lot on that front myself.
One thing with zato-apitest testing is that it can read variables to use
in test cases from environment (as in export MY_VAR=1). This is totally
cool and lets you, say, test whole environments in complete isolation
under Docker, before promoting code to the next environment.