Hi everyone,
thanks for all your suggestions. I've been beavering away, and I've got a
first draft of the chapter on deployment ready. I'd love your feedback!
You can find it at
http://chimera.labs.oreilly.com/books/123400754/ch08.html
Here's a broad outline of what I decided to go for:
P
On Mon, 20 May 2013, Andy Robinson wrote:
be run in a live web app. For example, for an online purchase
process, you might have a selenium test which steps right through a
purchase using a known "only for tests" account or credit card number.
[...]
I don't know what this kind of testing is ca
On Mon, 20 May 2013, MikedePlume wrote:
I must say, I'd love to see something about testing bash scripts, and,
Something like this:
child = subprocess.Popen(["find", deploy_root, "-name", "*.sh"])
out, err = child.communicate()
bad = out.splitlines()
self.assertEqual(len(bad), 0)
;-)
John
>
> It's REALLY useful to have a small set of "functional tests" which can
> be run in a live web app. For example, for an online purchase
> process, you might have a selenium test which steps right through a
> purchase using a known "only for tests" account or credit card number.
> And it's an a
On 20 May 2013 14:51, Harry Percival wrote:
> Also, question for django people: static files, as collected by "manage.py
> collectstatic": in the repo, or not?
No. It's a deployment step.
It's REALLY useful to have a small set of "functional tests" which can
be run in a live web app. For exa
On 20 May 2013 15:40, MikedePlume wrote:
> Interesting that the subject veers towards system design. I use FCGI
> myself and the restart can be entirely non-root. Provisioning then
> includes adding the FCGI reference into the server config.
>
I'm glad we're not the only ones. We have been ver
On Mon, 2013-05-20 at 14:51 +0100, Harry Percival wrote:
> Interesting points both. I think it's insightful to think about the
> line beween provisioning and deployment... The idea that deployment
> shouldn't require root permissions is a good stake in the ground.
>
>
> In the book I've decided
On 20 May 2013 14:51, Harry Percival wrote:
> Interesting points both. I think it's insightful to think about the line
> beween provisioning and deployment... The idea that deployment shouldn't
> require root permissions is a good stake in the ground.
>
> In the book I've decided I'm going to ta
On 20 May 2013, at 15:00, David Reynolds wrote:
>
> On 20 May 2013, at 14:51, Harry Percival wrote:
>
>> Also, question for django people: static files, as collected by "manage.py
>> collectstatic": in the repo, or not?
>
> Not. That is a deployment step in my book.
>
>
Agreed. Many ap
On 20 May 2013, at 14:51, Harry Percival wrote:
> Also, question for django people: static files, as collected by "manage.py
> collectstatic": in the repo, or not?
Not. That is a deployment step in my book.
--
David Reynolds
da...@reynoldsfamily.org.uk
Interesting points both. I think it's insightful to think about the line
beween provisioning and deployment... The idea that deployment shouldn't
require root permissions is a good stake in the ground.
In the book I've decided I'm going to take people through spinning up a
server with Apache, and
It doesn't need to be SSH-based, there are orchestration systems that are
RPC or pubsub based (eg. Jenkins, MCollective).
As per the line between provisioning and deployment I've argued in the past
that provisioning should be for state that spans many minor releases of an
application. I also belie
On Sat, 2013-05-18 at 17:41 +0100, Andy Robinson wrote:
> Daniel, who are you disagreeing with? Everyone here agrees on
> automation, I think.
>
> - Andy
As a small user (one or two servers, one or two packages to deploy):
I started by doing a lot of typing of commands, got bored with that,
mo
Just to second what Daniel is saying, I have found that generally we get much
higher quality outcomes using a deployment/management system (puppet/chef/salt)
over SSH/shell commands, such that I would even use it to manage repetitive
tasks on a single machine.
Kris
--
Kris Saxton
e: k...@autom
Daniel, who are you disagreeing with? Everyone here agrees on
automation, I think.
- Andy
On 18 May 2013 12:24, Daniel Pope wrote:
> I thoroughly disagree with those who are saying that for small
> installations, it's less time-consuming to do things manually. A
> deployment/provisioning sys
I thoroughly disagree with those who are saying that for small
installations, it's less time-consuming to do things manually. A
deployment/provisioning system gives you reproducibility - an executable
record of how to re-create a server configuration or re-run a deployment
without missing anything.
On 16.05.2013 17:46, Andy Robinson wrote:
> Speaking as a relatively obsolete dinosaur, I would suggest that if
> you are going to discuss specific deployment practices, you start with
> the most fundamental ones: SSH, the unix shell and so on.
>
> We have had issues over the years with people co
In a previous job I was asked to set up CI & (almost) automatic deployment for
a financial pricing library + UI which had a large multi-step build and an
annoying test-routine - which included loads of regression tests which had been
written in MS-Excel.
This was a desktop application used by
+1 from another dinosaur
Ed
On 16 May 2013, at 16:46, Andy Robinson wrote:
> Speaking as a relatively obsolete dinosaur, I would suggest that if
> you are going to discuss specific deployment practices, you start with
> the most fundamental ones: SSH, the unix shell and so on.
>
> We have had
I would like to second to Andy Robinson here - try to use less new sexy
tools and try to use an existing infrastructure.
For example, how we build & deploy web services*** at YPlan:
1. A bash script is executed (by Jenkins) on a build machine, which
generates an rpm package with [virtualenv + cod
Speaking as a relatively obsolete dinosaur, I would suggest that if
you are going to discuss specific deployment practices, you start with
the most fundamental ones: SSH, the unix shell and so on.
We have had issues over the years with people coming in and
introducing sexy new deployment tools, b
On 16 May 2013, at 11:52, Stestagg wrote:
> The Zope 'brand' got trashed back in the bad old days. If things have truly
> improved, then the sensible thing to do would be to release the new code in a
> way that has no obvious links to the name 'Zope', and let that stand on its
> own merits.
The Zope 'brand' got trashed back in the bad old days. If things have
truly improved, then the sensible thing to do would be to release the new
code in a way that has no obvious links to the name 'Zope', and let that
stand on its own merits.
Another factor here, is that the current trend is towar
On 16 May 2013, at 11:22, Tim Diggins wrote:
> PS at the risk of starting a flame war: "zc.buildout"… --shudder--
> Feels like there are two different python communities sometimes, those that
> use zope-derived rather java-flavoured tools and mindset, and the rest.
I don't want to start a flam
While we're on topic - what would people say is best practice for testing
of a web API in a way that slots cleanly into a CI setup? Lots of different
options out there, hence the q. (I realise this is also a bit like saying
how long is a piece of string)
Michael.
On 15 May 2013 10:57, Harry Per
Harry -
I think if you're teaching best practices on python and testing, you've got
to teach virtualenv - maybe not for deployment (cause better to have
separate VMs for staging and production) but for development and testing,
really important (unless you do everything in a vm, like vagrant or
sim
On 16 May 2013, at 09:02, Harry Percival wrote:
> Overall, it's both reassuring and depressing to hear that that there's no
> single accepted way to do it!
*snip*
because….
> We then start with "provisioning" -- that's getting a server up and running
> with Apache installed. Let's say that'
Hi everyone, thanks for some helpful thoughts!
@Tim, thanks for pointing out the distinction between provisioning and
deployment, I think that's helped to clarify things in my head a little...
@Alfredo, @Kris, and anyone else that's curious, you can already buy/read
the book, plug plug. I'm 6 c
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
41 matches
Mail list logo
