One point that's worth mentioning in this context:
If you rely on building native libraries for custom Python packages of your own
or those created by third parties consider avoiding the automatic systems that
do security updates in the background.
We had a sysadmin at point who insisted on this
Harry, are you anywhere near London? If so, you would be welcome to
pop into ReportLab some time and we could tell you endless war stories
about deployment. I remember giving a talk on the subject at
EuroPython in 2003 and basically scaring the hell out of all the small
startups present about how
On 15 May 2013, at 10:57, Harry Percival wrote:
> Dear UK Python chums,
>
> some of you probably know I'm writing a book about TDD for O'Reilly. I'm
> looking for some help with the (first) chapter on deployment.
>
> http://www.obeythetestinggoat.com/what-to-say-about-deployment.html
>
> Wha
To add a slightly different angle to this, whatever deployment solution you
use, make sure it is fully automated, and then hook it into you CI system.
Deployment, disaster recovery etc. are made so much simpler if you're
thinking about it from the start rather than just before release. One way
to
Every other reply completely failed at TDD! Write the test first to see if
the URL is responding(oh, maybe test if the domain name is registered and
trademarked first?)?
Also, there's no best practices for python deployment... just a bunch of
random hacks. You'll learn that moving to different pr
Hi Harry,
I would use salt(http://docs.saltstack.com/index.html) for provisioning
and keep the python specific package to fabric to deploy using pip.
Even though salt is able to deploy pip requirements but I think this
separation is important.
Mustafiz.
On 15/05/2013 11:34, George Hickman
Hi Harry (and list)
Just to expand on what George was saying.
Salt (http://saltstack.com) is a remote execution (fabric) and configuration
management (puppet, chef) framework written in Python and using ZeroMQ as the
transport. I do automation for a living, started with puppet but now prefer t
For small websites ( upto 3 - 4 VMs ) I use fabric. I define small modular
tasks that get executed in AWS EC2.
I wrote a bunch of scripts around a year before for the same:
https://github.com/gargdeepak/django-cloud
Its not tested for quite some time and should be read well before being
used.
For
Hi Harry,
I use two methods for deployment - Heroku and Ubuntu VPSs.
Heroku is really simple to get going but gets expensive if you want to run
a serious production app. However it's probably what I'd recommend for
beginners since so much is done for you and they have first class python
support.
A very quick rundown of my process:
* Custom script to build and send to a packages server:
- deleting things like Cythoned files and generated .so files which setup.py
likes to try to avoid recompiling even if you want it to.
- setup.py build_ext
- setup.py sdist -d dist.$TEMP
- scp
Hi Harry,
I will get a copy of your book once it is out. I loved the hands-on workshop
you gave in London a while ago.
Maybe cuisine can help: https://github.com/sebastien/cuisine is a set of
scripts to bootstrap applications via fabric.
I've been working in a vagrant + puppet setup for a loca
Hi Harry (and list)
First - I think you should separate out provisioning (setting up the server
and all the dependencies and maybe the initial install) from deployment
(repeatedly updating the site based on the latest codebase and db
migrations etc).
Secondly - my experience (which may not be ver
Dear UK Python chums,
some of you probably know I'm writing a book about TDD for O'Reilly. I'm
looking for some help with the (first) chapter on deployment.
http://www.obeythetestinggoat.com/what-to-say-about-deployment.html
What do you use for deployment? Do you have any kind of automated scr
13 matches
Mail list logo
