Organizing Projects

[Greg Lindstrom <Gr...@NovaSysHealth.com>]

Hello,

I am the IT manager at Novasys Health, Inc. where we process claims for the health care industry.  We have started using Subversion as our code repository (from cvs) and I am still struggling with how to set up projects.  Most of our code is in Python, though we have a lot of stored procedures (Postgres and Oracle) and some Perl code.

Traditionally, we set up a "trunk", "branches" and "tags" directory in Subversion for each project.  I have a good feel for creating branches, making changes, merging back to the trunk and creating a tag.  What I would like advice on is how to migrate to production.  Currently, after I make a tag I will check it out to a "distros" directory (named the same as the tag) and then change a pointer from the "old" distro to the new one.  This way we have a history of distros and it's easy to revert back if an error is found.  The problem I have with this setup is that is what Subversion is designed to do for me (keep track of changes).

An option I have been considering is to create another directory under the project called "prod" that we check out to our production environments.  Any production tags would be merged into this branch and then we would "update" the production environment with the new code.  This would, I believe, give a nice change history in the svn log.

Another option is to create a "zip" file once a distribution tag is created.  The zip file would be placed out on the network for people to install as needed.  I don't care for this idea, but I know a large company that does it and it seems to work.

What advice can you give me?  Is there a better way?  What do I Google to find out more?  Where do I go for help?  We've done a fairly good job on a small scale, but we're growing and I want to get something THAT WORKS in place.

Thanks for your thoughts,

--greg

Greg Lindstrom, IT Manager                        501-975-4859
Novasys Health, Inc.                           Fax: 501 219-4455
10801 Executive Center Dr.
Little Rock, AR   72211
We are the music makers, and we are the dreamers of dreams


CONFIDENTIALITY NOTICE:  This communication contains information 
intended for the use of the individuals to whom it is addressed 
and may contain information that is privileged, confidential or 
exempt from other disclosure under applicable law.  If you are 
not the intended recipient, you are notified that any disclosure, 
printing, copying, distribution or use of the contents is prohibited.  
If you have received this in error, please notify the sender 
immediately by telephone or by returning it by return mail and then 
permanently delete the communication from your system.  Thank you.

Re: Organizing Projects

[Nico Kadel-Garcia <nk...@gmail.com>]

On Mon, Mar 21, 2011 at 6:16 AM, Ryan Schmidt
<su...@ryandesign.com> wrote:
> On Mar 18, 2011, at 14:33, Greg Lindstrom wrote:
>
>> Traditionally, we set up a "trunk", "branches" and "tags" directory in Subversion for each project.  I have a good feel for creating branches, making changes, merging back to the trunk and creating a tag.  What I would like advice on is how to migrate to production.  Currently, after I make a tag I will check it out to a "distros" directory (named the same as the tag) and then change a pointer from the "old" distro to the new one.  This way we have a history of distros and it's easy to revert back if an error is found.  The problem I have with this setup is that is what Subversion is designed to do for me (keep track of changes).
>>
>> An option I have been considering is to create another directory under the project called "prod" that we check out to our production environments.  Any production tags would be merged into this branch and then we would "update" the production environment with the new code.  This would, I believe, give a nice change history in the svn log.

It might be much simpler to set up a "deploy" directory with
"svn:extern" set to point to your production tag. This allows you to
do an "update" of that working copy as part of any procedure you wish,
even "post-commit", and deploy that. Just make sure that the
svn:extern is stable and points to well defined targets. It doesn't
even have to live in the same Subversion repository this way.

>> Another option is to create a "zip" file once a distribution tag is created.  The zip file would be placed out on the network for people to install as needed.  I don't care for this idea, but I know a large company that does it and it seems to work.

E-e-e-e-e-w-w-w-w-w-w-w.

>> What advice can you give me?  Is there a better way?  What do I Google to find out more?  Where do I go for help?  We've done a fairly good job on a small scale, but we're growing and I want to get something THAT WORKS in place.
>
> Consider using SVN::Notify::Mirror, a perl module explained by its author here:
>
> http://svn.haxx.se/users/archive-2006-02/1148.shtml
>
> The theory of operation is that, whenever you want to deploy something to production, you simply create a tag following a certain naming scheme (that you can define). A post-commit hook in the repository runs SVN::Notify::Mirror which notices when new production tags are created and mirrors their contents to your production server.

Which involves creating unnecessary perl modules. A simple svn:extern
allows tracking of the production release itself.

Re: Organizing Projects

[Ryan Schmidt <su...@ryandesign.com>]

On Mar 18, 2011, at 14:33, Greg Lindstrom wrote:

> Traditionally, we set up a "trunk", "branches" and "tags" directory in Subversion for each project.  I have a good feel for creating branches, making changes, merging back to the trunk and creating a tag.  What I would like advice on is how to migrate to production.  Currently, after I make a tag I will check it out to a "distros" directory (named the same as the tag) and then change a pointer from the "old" distro to the new one.  This way we have a history of distros and it's easy to revert back if an error is found.  The problem I have with this setup is that is what Subversion is designed to do for me (keep track of changes).
>  
> An option I have been considering is to create another directory under the project called "prod" that we check out to our production environments.  Any production tags would be merged into this branch and then we would "update" the production environment with the new code.  This would, I believe, give a nice change history in the svn log.
>  
> Another option is to create a "zip" file once a distribution tag is created.  The zip file would be placed out on the network for people to install as needed.  I don't care for this idea, but I know a large company that does it and it seems to work.
>  
> What advice can you give me?  Is there a better way?  What do I Google to find out more?  Where do I go for help?  We've done a fairly good job on a small scale, but we're growing and I want to get something THAT WORKS in place.

Consider using SVN::Notify::Mirror, a perl module explained by its author here:

http://svn.haxx.se/users/archive-2006-02/1148.shtml

The theory of operation is that, whenever you want to deploy something to production, you simply create a tag following a certain naming scheme (that you can define). A post-commit hook in the repository runs SVN::Notify::Mirror which notices when new production tags are created and mirrors their contents to your production server.