Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.

#1 Dec. 22, 2010 18:40:57

D.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


I've been bashing my head against a wall lately trying to determine
the best (highly subjective, I know) workflow for developing Django
projects.

What I have gathered so far is:

* Buildout -- For building and packaging your projects.
* Fabric -- For easy deployment/testing of code on devel/staging/
production servers
* PIP -- For installing Python packages into your project.
* virtualenv -- For creating an isolated Python environment.

... but what I am having trouble figuring out is how the workflow
should be between these tools.

* What's the relationship between PIP and buildout in development vs.
deployment?
* Is buildout used solely for installing/packaging stuff for
deployment?
* Do you use fabric to run buildout on a server?
* What role does PIP requirements file play in all this? Is it used?
* Are you using setuptools or distribute?

I know this is a very broad and subjective topic but I'd love to hear
what you guys and gals are doing out there to develop rapidly and to
deploy efficiently and predictably.

Cheers

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#2 Dec. 22, 2010 19:12:11

S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


Hi

After working on couple of big projects I felt the best way to start on
django once you have the basic setup ready is

1.) Have a complete list of the features into your requirement documents
if its not possible and you want a agile development methodology split
into features that makes sense w.r.t sub-releases

2.) understand what all external django apps you may need and go through
their documentation as well

3.) Create the db model as completely as possible i.e include any future
fields that you need, or you feel could be important for you project,
addressing in the first go would be great
( I messed up DB modelling and I had to redo quite some )

4.) Start working on the views page by page w.r.t the requirement

5.) Have the unit test case after you are done ( or even before you develop
if you are using TDD model )

6.) once you feel complete then go for selenium , deployment automation, ...
and the rest


Subramanyam


On Thu, Dec 23, 2010 at 12:10 AM, Dana <woodman.d...@gmail.com> wrote:

> I've been bashing my head against a wall lately trying to determine
> the best (highly subjective, I know) workflow for developing Django
> projects.
>
> What I have gathered so far is:
>
> * Buildout -- For building and packaging your projects.
> * Fabric -- For easy deployment/testing of code on devel/staging/
> production servers
> * PIP -- For installing Python packages into your project.
> * virtualenv -- For creating an isolated Python environment.
>
> ... but what I am having trouble figuring out is how the workflow
> should be between these tools.
>
> * What's the relationship between PIP and buildout in development vs.
> deployment?
> * Is buildout used solely for installing/packaging stuff for
> deployment?
> * Do you use fabric to run buildout on a server?
> * What role does PIP requirements file play in all this? Is it used?
> * Are you using setuptools or distribute?
>
> I know this is a very broad and subjective topic but I'd love to hear
> what you guys and gals are doing out there to develop rapidly and to
> deploy efficiently and predictably.
>
> Cheers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
>http://groups.google.com/group/django-users?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#3 Dec. 22, 2010 19:21:28

D.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


Subramanyam, thanks for the response.

In regard to 3, I am not clear why it would be a good idea to add in
model fields for things you *think* you might want some day.

I would think that using Django South or something similar to create
SQL migrations for your model after a change would be a cleaner
solution... I don't like the idea of adding fields to a model that I
will not use right away as it adds cruft and complexity to my models
and makes it so determining what is being used and what is not more
difficult. Also, since you would be planning for the future, there is
a good chance things will change so much that it would render those
fields obsolete or inaccurate.

Do you use PIP, virtualenv or any of the other tools I mentioned in my
first post?

Cheers

On Dec 22, 11:12 am, Subramanyam <balu.v...@gmail.com> wrote:
> Hi
>
> After working on couple of big projects I felt the best way to start on
> django once you have the basic setup ready is
>
> 1.) Have a complete list of the features into your requirement documents
>     if its not possible and you want a agile development methodology split
> into features that makes sense w.r.t sub-releases
>
> 2.) understand what all external django apps you may need and go through
> their documentation as well
>
> 3.) Create the db model as completely as possible i.e include any future
> fields that you need, or you feel could be important for you project,
>  addressing in the first go would be great
> ( I messed up DB modelling and I had to redo quite some )
>
> 4.) Start working on the views page by page w.r.t the requirement
>
> 5.) Have the unit test case after you are done ( or even before you develop
> if you are using TDD model )
>
> 6.) once you feel complete then go for selenium , deployment automation, ...
> and the rest
>
> Subramanyam
>
> On Thu, Dec 23, 2010 at 12:10 AM, Dana <woodman.d...@gmail.com> wrote:
> > I've been bashing my head against a wall lately trying to determine
> > the best (highly subjective, I know) workflow for developing Django
> > projects.
>
> > What I have gathered so far is:
>
> > * Buildout -- For building and packaging your projects.
> > * Fabric -- For easy deployment/testing of code on devel/staging/
> > production servers
> > * PIP -- For installing Python packages into your project.
> > * virtualenv -- For creating an isolated Python environment.
>
> > ... but what I am having trouble figuring out is how the workflow
> > should be between these tools.
>
> > * What's the relationship between PIP and buildout in development vs.
> > deployment?
> > * Is buildout used solely for installing/packaging stuff for
> > deployment?
> > * Do you use fabric to run buildout on a server?
> > * What role does PIP requirements file play in all this? Is it used?
> > * Are you using setuptools or distribute?
>
> > I know this is a very broad and subjective topic but I'd love to hear
> > what you guys and gals are doing out there to develop rapidly and to
> > deploy efficiently and predictably.
>
> > Cheers
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#4 Dec. 22, 2010 19:58:41

W. C.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


Dana ...

How you build and deploy your project will be shaped by the environment
where you're deploying. Thus my choices about "best practices" will be very
different that yours. That said, here are my thoughts (worth exactly what
they cost you):


- You're definitely right about using South migrations to allow you to
refactor your database model as needed. (I wish I could use it on my
current project -- long story that I can't tell.) If you do intend to use
South, start using it early, instead of adding it in later.
- VirtualEnv and Pip have proven very useful to me in several
environments -- the ability to easily install and uninstall packages into a
controlled environment is critical when you are deploying to servers where
you don't have administrative access (ie: hosting environments).
- Most of the Python package infrastructure (pip, setuptools, distribute)
believes that it will be used on systems that are connected to the Internet,
and their developers rarely test anything without a live connection to the
Internet, which means that frequently the tools are broken for offline use.
(Note that once you point out the breakage, they will fix it, but it can be
confusing for the unwary).

- Craig -

On Wed, Dec 22, 2010 at 13:40, Dana <woodman.d...@gmail.com> wrote:

> I've been bashing my head against a wall lately trying to determine
> the best (highly subjective, I know) workflow for developing Django
> projects.
>
> What I have gathered so far is:
>
> * Buildout -- For building and packaging your projects.
> * Fabric -- For easy deployment/testing of code on devel/staging/
> production servers
> * PIP -- For installing Python packages into your project.
> * virtualenv -- For creating an isolated Python environment.
>
> ... but what I am having trouble figuring out is how the workflow
> should be between these tools.
>
> * What's the relationship between PIP and buildout in development vs.
> deployment?
> * Is buildout used solely for installing/packaging stuff for
> deployment?
> * Do you use fabric to run buildout on a server?
> * What role does PIP requirements file play in all this? Is it used?
> * Are you using setuptools or distribute?
>
> I know this is a very broad and subjective topic but I'd love to hear
> what you guys and gals are doing out there to develop rapidly and to
> deploy efficiently and predictably.
>
> Cheers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
>http://groups.google.com/group/django-users?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#5 Dec. 22, 2010 20:41:52

S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


hi Dana


On Thu, Dec 23, 2010 at 12:51 AM, Dana <woodman.d...@gmail.com> wrote:

> Subramanyam, thanks for the response.
>
> In regard to 3, I am not clear why it would be a good idea to add in
> model fields for things you *think* you might want some day.
>
> I would think that using Django South or something similar to create
> SQL migrations for your model after a change would be a cleaner
> solution... I don't like the idea of adding fields to a model that I
> will not use right away as it adds cruft and complexity to my models
> and makes it so determining what is being used and what is not more
> difficult. Also, since you would be planning for the future, there is
> a good chance things will change so much that it would render those
> fields obsolete or inaccurate.
>

My point exactly is to lessen the changes that one may want to say I can do
them later and that ends up being a daunting task later
( personally we have re factored much of the code that way)

The fields I mentioned are mostly relation for tables that would be part of
your project but which are required to be implemented later

South is a good tool, but my point is its better not to get to the point
that we have to use South
( Invariably we end up with that its a different case )

Regarding changes of DB, we dont want to predict that there may be many
changes, that I dont know now, instead I feel it should be "I have
estimated all of the project`s DB schema now as per the features and dont
need anymore unless the features are completely changed

- Subramanyam

>
> Do you use PIP, virtualenv or any of the other tools I mentioned in my
> first post?
>
> Cheers
>
> On Dec 22, 11:12 am, Subramanyam <balu.v...@gmail.com> wrote:
> > Hi
> >
> > After working on couple of big projects I felt the best way to start on
> > django once you have the basic setup ready is
> >
> > 1.) Have a complete list of the features into your requirement documents
> > if its not possible and you want a agile development methodology
> split
> > into features that makes sense w.r.t sub-releases
> >
> > 2.) understand what all external django apps you may need and go through
> > their documentation as well
> >
> > 3.) Create the db model as completely as possible i.e include any future
> > fields that you need, or you feel could be important for you project,
> > addressing in the first go would be great
> > ( I messed up DB modelling and I had to redo quite some )
> >
> > 4.) Start working on the views page by page w.r.t the requirement
> >
> > 5.) Have the unit test case after you are done ( or even before you
> develop
> > if you are using TDD model )
> >
> > 6.) once you feel complete then go for selenium , deployment automation,
> ...
> > and the rest
> >
> > Subramanyam
> >
> > On Thu, Dec 23, 2010 at 12:10 AM, Dana <woodman.d...@gmail.com> wrote:
> > > I've been bashing my head against a wall lately trying to determine
> > > the best (highly subjective, I know) workflow for developing Django
> > > projects.
> >
> > > What I have gathered so far is:
> >
> > > * Buildout -- For building and packaging your projects.
> > > * Fabric -- For easy deployment/testing of code on devel/staging/
> > > production servers
> > > * PIP -- For installing Python packages into your project.
> > > * virtualenv -- For creating an isolated Python environment.
> >
> > > ... but what I am having trouble figuring out is how the workflow
> > > should be between these tools.
> >
> > > * What's the relationship between PIP and buildout in development vs.
> > > deployment?
> > > * Is buildout used solely for installing/packaging stuff for
> > > deployment?
> > > * Do you use fabric to run buildout on a server?
> > > * What role does PIP requirements file play in all this? Is it used?
> > > * Are you using setuptools or distribute?
> >
> > > I know this is a very broad and subjective topic but I'd love to hear
> > > what you guys and gals are doing out there to develop rapidly and to
> > > deploy efficiently and predictably.
> >
> > > Cheers
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Django users" group.
> > > To post to this group, send email to django-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> <django-users%2bunsubscr...@googlegroups.com<django-users%252bunsubscr...@googlegroups.com>
> >
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
>http://groups.google.com/group/django-users?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#6 Dec. 22, 2010 22:04:49

Cal L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


Apologies if I have repeated what anyone else has said, or if some ofthese comments aren't directly related, but here's my two cents worth.And remember, rapid development isn't always about the different piecesof software or frameworks that you use, so hopefully some of the belowcomments give some food for thought.* Make sure your workflow is sensible for the size of the project
you are working on. For example, there's no point putting
significant time into enterprise grade unit testing, if the app is
not business critical, or the client doesn't want to pay too much.

* If the project is in-house (i.e. its one of your own projects),
then these are the best times to experiment with new methods and
solutions, because then you are not putting your clients product
at risk, and you learn from mistakes the easy way. (we've all been
there!)

* It is nice to use isolated Python environments where ever
possible, but remember, they will need to be maintained manually
(for security patches etc). This does have its benefits, for
example if your Django app has dependancies for a specific version
of a module, and the sys admin upgrades Python, and thus breaks
your app.

* Before you even touch anything, make sure you have a spec from the
client first. This is absolutely crucial if you want an easy life.
Again, if this is your own project, you may choose to either draw
up a spec to give you a good idea as to how one should look
(you'll learn along the way), or think up the spec as you go
along. Some clients will say there is no spec, and that they are
thinking of things off the top of their head. In these cases, you
must *insist* that you work on a daily rate, no exceptions,
otherwise clients will take you for a ride (again, we've all been
there before).

* It's good to start with the database models first, to make sure
that the underlaying foundations of your application are sound.
Try to anticipate future modifications, and don't bother too much
with tuning to begin with. As long as you have some decent skills
in the database you have chosen to use, then it is an easy enough
task to create indexes along the way etc.

* If you want to test work flow, then try and make good use of the
"manage.py shell" and also the ability to create management
commands. This will allow you to quickly test code changes,
without having to do app restarts, or going through login
processes. I know this sounds like a minimal amount of time saves,
but when you're doing 200-300 test runs a day, it soon adds up!
Again, use your own discretion as to whether this approach is
sensible for the size of the project.Also, as a side comment, I haven't used either buildout or fabric, so Ican't offer much advice on these.On 22/12/2010 18:40, Dana wrote:I've been bashing my head against a wall lately trying to determine
the best (highly subjective, I know) workflow for developing Django
projects.

What I have gathered so far is:

* Buildout -- For building and packaging your projects.
* Fabric -- For easy deployment/testing of code on devel/staging/
production servers
* PIP -- For installing Python packages into your project.
* virtualenv -- For creating an isolated Python environment.

... but what I am having trouble figuring out is how the workflow
should be between these tools.

* What's the relationship between PIP and buildout in development vs.
deployment?
* Is buildout used solely for installing/packaging stuff for
deployment?
* Do you use fabric to run buildout on a server?
* What role does PIP requirements file play in all this? Is it used?
* Are you using setuptools or distribute?

I know this is a very broad and subjective topic but I'd love to hear
what you guys and gals are doing out there to develop rapidly and to
deploy efficiently and predictably.

Cheers--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#7 Dec. 22, 2010 22:12:48

r.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


>     * If you want to test work flow, then try and make good use of the
>       "manage.py shell" and also the ability to create management
>       commands. This will allow you to quickly test code changes,
>       without having to do app restarts, or going through login
>       processes.

Cal, would you be willing to elaborate a bit on this point, or maybe
share an example?

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#8 Dec. 22, 2010 22:43:10

Cal L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


Sure thing.In several previous projects, they required the user to upload a filevia the browser (usually above 10mb), and this was then sent off intothe queuing system to be processed. Now, because of the huge amounts oftime it took to upload, we instead created a management command, whichdid a file read directly from disk rather than requiring an upload eachtime. At the same time, the command also spat out huge amounts of debugduring processing, so when we needed to figure out why the adapter (i.e.the piece of code that was scanning for content inside the file) wasn'tworking, we could easily do this without the overhead of uploading andwaiting for debug emails to come back from the queuing system.As for the django shell, this is extremely useful for testing individualpieces of code on the fly. It is a tad annoying that if any of thepython modules change after being imported, reload() doesn't seem toplay nicely all the time, so this usually means restarting the shell.But, for things like model lookups etc, I find it a great deal easierthan writing huge chunks of SELECT SQL.On 22/12/2010 22:12, ringemup wrote:* If you want to test work flow, then try and make good use of the
"manage.py shell" and also the ability to create management
commands. This will allow you to quickly test code changes,
without having to do app restarts, or going through login
processes.Cal, would you be willing to elaborate a bit on this point, or maybe
share an example?--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#9 Dec. 22, 2010 22:50:36

r.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


Thanks, Cal -- that's extremely helpful.

On Dec 22, 5:42 pm, "Cal Leeming "
<cal.leem...@simplicitymedialtd.co.uk> wrote:
> Sure thing.
>
> In several previous projects, they required the user to upload a file
> via the browser (usually above 10mb), and this was then sent off into
> the queuing system to be processed. Now, because of the huge amounts of
> time it took to upload, we instead created a management command, which
> did a file read directly from disk rather than requiring an upload each
> time. At the same time, the command also spat out huge amounts of debug
> during processing, so when we needed to figure out why the adapter (i.e.
> the piece of code that was scanning for content inside the file) wasn't
> working, we could easily do this without the overhead of uploading and
> waiting for debug emails to come back from the queuing system.
>
> As for the django shell, this is extremely useful for testing individual
> pieces of code on the fly. It is a tad annoying that if any of the
> python modules change after being imported, reload() doesn't seem to
> play nicely all the time, so this usually means restarting the shell.
> But, for things like model lookups etc, I find it a great deal easier
> than writing huge chunks of SELECT SQL.
>
> On 22/12/2010 22:12, ringemup wrote:
>
> >>      * If you want to test work flow, then try and make good use of the
> >>        "manage.py shell" and also the ability to create management
> >>        commands. This will allow you to quickly test code changes,
> >>        without having to do app restarts, or going through login
> >>        processes.
> > Cal, would you be willing to elaborate a bit on this point, or maybe
> > share an example?
>
>

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

#10 Dec. 24, 2010 05:02:40

D.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

What's your workflow?


@Subramanyam

> South is a good tool, but my point is its better not to get to the point
> that we have to use South.

Why do you think South is a fallback rather than part of your toolset?
>From what I can see it is a great tool and adds a lot of great
features to a Django developers arsenal.


On Dec 22, 12:41 pm, Subramanyam <balu.v...@gmail.com> wrote:
> hi Dana
>
> On Thu, Dec 23, 2010 at 12:51 AM, Dana <woodman.d...@gmail.com> wrote:
> > Subramanyam, thanks for the response.
>
> > In regard to 3, I am not clear why it would be a good idea to add in
> > model fields for things you *think* you might want some day.
>
> > I would think that using Django South or something similar to create
> > SQL migrations for your model after a change would be a cleaner
> > solution... I don't like the idea of adding fields to a model that I
> > will not use right away as it adds cruft and complexity to my models
> > and makes it so determining what is being used and what is not more
> > difficult. Also, since you would be planning for the future, there is
> > a good chance things will change so much that it would render those
> > fields obsolete or inaccurate.
>
> My point exactly is to lessen the changes that one may want to say I can do
> them later and that ends up being a daunting task later
> ( personally we have re factored much of the code that way)
>
> The fields I mentioned are mostly relation for tables that would be part of
> your project but which are required to be implemented later
>
> South is a good tool, but my point is its better not to get to the point
> that we have to use South
> ( Invariably we end up with that its a different case )
>
> Regarding changes of DB, we dont want to predict that there may be many
> changes, that I dont know now,  instead I feel it should be "I have
> estimated all of the project`s DB schema now as per the features and dont
> need anymore unless the features are completely changed
>
> - Subramanyam
>
>
>
> > Do you use PIP, virtualenv or any of the other tools I mentioned in my
> > first post?
>
> > Cheers
>
> > On Dec 22, 11:12 am, Subramanyam <balu.v...@gmail.com> wrote:
> > > Hi
>
> > > After working on couple of big projects I felt the best way to start on
> > > django once you have the basic setup ready is
>
> > > 1.) Have a complete list of the features into your requirement documents
> > >     if its not possible and you want a agile development methodology
> > split
> > > into features that makes sense w.r.t sub-releases
>
> > > 2.) understand what all external django apps you may need and go through
> > > their documentation as well
>
> > > 3.) Create the db model as completely as possible i.e include any future
> > > fields that you need, or you feel could be important for you project,
> > >  addressing in the first go would be great
> > > ( I messed up DB modelling and I had to redo quite some )
>
> > > 4.) Start working on the views page by page w.r.t the requirement
>
> > > 5.) Have the unit test case after you are done ( or even before you
> > develop
> > > if you are using TDD model )
>
> > > 6.) once you feel complete then go for selenium , deployment automation,
> > ...
> > > and the rest
>
> > > Subramanyam
>
> > > On Thu, Dec 23, 2010 at 12:10 AM, Dana <woodman.d...@gmail.com> wrote:
> > > > I've been bashing my head against a wall lately trying to determine
> > > > the best (highly subjective, I know) workflow for developing Django
> > > > projects.
>
> > > > What I have gathered so far is:
>
> > > > * Buildout -- For building and packaging your projects.
> > > > * Fabric -- For easy deployment/testing of code on devel/staging/
> > > > production servers
> > > > * PIP -- For installing Python packages into your project.
> > > > * virtualenv -- For creating an isolated Python environment.
>
> > > > ... but what I am having trouble figuring out is how the workflow
> > > > should be between these tools.
>
> > > > * What's the relationship between PIP and buildout in development vs.
> > > > deployment?
> > > > * Is buildout used solely for installing/packaging stuff for
> > > > deployment?
> > > > * Do you use fabric to run buildout on a server?
> > > > * What role does PIP requirements file play in all this? Is it used?
> > > > * Are you using setuptools or distribute?
>
> > > > I know this is a very broad and subjective topic but I'd love to hear
> > > > what you guys and gals are doing out there to develop rapidly and to
> > > > deploy efficiently and predictably.
>
> > > > Cheers
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Django users" group.
> > > > To post to this group, send email to django-us...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> > <django-users%2bunsubscr...@googlegroups.com<django-users%252bunsubscr...@googlegroups.com>
>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/django-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.

--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.

Offline

Board footer

Moderator control

Enjoy the 19th of August
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support