CodeIgniter Forums
version control and development - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived Development & Programming (https://forum.codeigniter.com/forumdisplay.php?fid=23)
+--- Thread: version control and development (/showthread.php?tid=34468)

Pages: 1 2

version control and development - El Forum - 09-30-2010

[eluser]frist44[/eluser]
We have a website going live soon and I was just curious how you guys are handling source code versioning. We will have a live server. My thought was to provision another server with a subdomain to act a development server to test changes. I'm currently the only developer, but we will add more. So I thought about adding git to the development machine and then put the code to the development box for everyone to really test in a similar environment as the production server.

Does this sound reasonable? or this there a better way to do it?

version control and development - El Forum - 09-30-2010

[eluser]WanWizard[/eluser]
Depending on the (age of the) project, we use either subversion or mercurial. We have some git repo's, because we need to sync with upstream repo's, but that's not the standard.

All developers develop locally, using a LAMP environment. When they commit (in case of svn) or push (in case of mercurial), the update is immediately exported to a staging (or integration) server using commit hooks. This server therefore runs the bleeding edge, as present in the repo.

When a release is tested and ready for production, the state of the repo is tagged, and this tagged version is automatically deployed to the production servers.

version control and development - El Forum - 09-30-2010

[eluser]frist44[/eluser]
I have no interest in getting into a big war, but what made you choose Mercurial over Git?

version control and development - El Forum - 09-30-2010

[eluser]Krzemo[/eluser]
In large corporations (ie. HP) there are usually 4 stages:
1) DEV - for development
2) QA - for quality assurance
3) UAT - user acceptance testing
4) PROD
First two loosely reflect PROD environment, but UAT is supposed to be 1:1 mirror.
Im pretty sure that having QA stage that is exact mirror of your PROD environment will be sufficient.
But changes and code versioning is just one thing. Dealing with DB changes when there is lots of user's data already might be more tricky. Especially when there is number of developers working on one application. Creating "dedicated engine" for DB versioning which is part of application in DEV stage might help alot. Below is short idea description. All changes/versions could be made as one or series of ALTER TABLE statements stored in separate files named in db001.sql, db002.sql, .... On local DEV there also should be additional DB table named i.e. db_ver storing what dbxxx.sql files have been already ran. Developers run i.e. /database/update url after each update/checkout from svn.

hope it helps a bit
Regs
K.

version control and development - El Forum - 09-30-2010

[eluser]bretticus[/eluser]
My work environment is a bit smaller with usually me and one more developer working together. We are "old school" and work via our subversion repositories. We both work off MacBook Pros and use MAMP to closely emulate our LAMP stacked services. Because our projects are typically frequent and smaller (custom programming for customers,) we do not have a staging server as much of the work and debugging is done before the website is ever released to the general public. All testing is done before commiting code (We accomplish this by setting up virtual hosts in MAMP and using /etc/hosts to set the host headers for the local vhost.) We do not use commit hooks, we simply check out a copy for our live website and update the live copy after a commit. This is, perhaps, a bit haphazard, but a very simple way to collaborate on source code and deploy to production.

The reason I posted is that I typically leave some key files out of the respository:

application/config/config.php
application/config/database.php

As these will most likely be different depending form where they are deployed. To make life easier, we create copies of the files:

application/config/config.sample.php
application/config/database.sample.php

and add those the repository so it's easy to just copy the sample and enter the local settings.

That said, I think WanWizard's approach is much better than ours (then again, we're keeping it simple for the reasons aforementioned.)

Good luck!

version control and development - El Forum - 09-30-2010

[eluser]frist44[/eluser]
[quote author="Cshamoh" date="1285885033"]In large corporations (ie. HP) there are usually 4 stages:
1) DEV - for development
2) QA - for quality assurance
3) UAT - user acceptance testing
4) PROD
First two loosely reflect PROD environment, but UAT is supposed to be 1:1 mirror.
Im pretty sure that having QA stage that is exact mirror of your PROD environment will be sufficient.
But changes and code versioning is just one thing. Dealing with DB changes when there is lots of user's data already might be more tricky. Especially when there is number of developers working on one application. Creating "dedicated engine" for DB versioning which is part of application in DEV stage might help alot. Below is short idea description. All changes/versions could be made as one or series of ALTER TABLE statements stored in separate files named in db001.sql, db002.sql, .... On local DEV there also should be additional DB table named i.e. db_ver storing what dbxxx.sql files have been already ran. Developers run i.e. /database/update url after each update/checkout from svn.

hope it helps a bit
Regs
K.[/quote]

I know this may be shocking Wink, but let's assume that I'm not a big as HP...

version control and development - El Forum - 09-30-2010

[eluser]WanWizard[/eluser]
[quote author="frist44" date="1285882447"]I have no interest in getting into a big war, but what made you choose Mercurial over Git?[/quote]
No preference really.

We made the decision to start moving from subversion to a distributed vcs at about the same time we've switched to CI 2. Hence Mercurial over Git.

I haven't seen any major differences between the two, but we don't really use most of the features. The advantage is mainly that you have a repo locally, so you can do local commits (and reverts), without bothering the others. Once you're happy, you push the changes to the central repo. Something you can't do with Subversion, which means you have to branch more, which in turn means big repo's.

version control and development - El Forum - 09-30-2010

[eluser]CroNiX[/eluser]
We use GIT. We have the customers live server and then a development server, dev.customerdomain.com. All developers work locally using git and commit their changes to the repo where they are then pulled to the dev server and tested. If everything is up to par, the changes then get pulled to the live server.

They maintain separate databases and other things, which uses a common config to dynamically tell it which resources, like db, to use depending on if its on the Production Server or the Testing Server.

The first line of my index.php file is this:
define('LIVE_SERVER', (strtolower($_SERVER['SERVER_NAME']) == 'dev.customerdomain.com') ? FALSE : TRUE);

Then in my config and other places I can do things like:

$config['base_url'] = (LIVE_SERVER) ? "http://www.customerdomain.com/" : 'http://dev.customerdomain.com';

$db['default']['database'] = (LIVE_SERVER) ? 'live_database' : 'dev_database';

We have found using a testing server to be very beneficial and saves a lot of time. It also lets the client preview and approve changes easily before they are implemented on the live server.

version control and development - El Forum - 09-30-2010

[eluser]cahva[/eluser]
I've tested a couple of versioning tools. Started with Bazaar, then used GIT for a while and now settled using Mercurial. Mercurial has couple of benefits over GIT for our development. 1. IMO Its a little bit more windows friendly and 2. Netbeans supports it out of the box(and 3. CI switched to it also Wink ).

Workflow is almost identical with CroNix. If there is only one dev doing changes to some project, he/she can do changes directly to the site on that server and after he/she is finished, does a commit at the end of the day. Then if the changes are ready for live, all we have to do is pull the changes and update on the live server. This is done by connecting server via SSH and do the pull+update from there.

When I work home, I use Wamp and do the changes locally and when I'm done, I commit+push the changes to project server. If the changes are ready for live, I SSH to the live server and pull+update the changes from project server.

version control and development - El Forum - 10-01-2010

[eluser]n0xie[/eluser]
We are still migrating from SVN to Git. The workflow we have reflects much of what Cshamoh has outlined, but every step is a different branch instead of being a complete different server.

I advice all who work with a SCM to read A successful Git branching model