Welcome Guest, Not a member yet? Register   Sign In
Development Environment Setup
#1

[eluser]jleequeen[/eluser]
Hello Everyone,

I thought it would be interesting to hear how some of my fellow CI's have their development environment setup. In particular those who work in small shops (1-2 developers) and develop locally and then copy code to the production server.

Before CI, It was really easy. I use Dreamweaver and had a site set up where basically when I was happy locally with a change, I could synchronize the remote site and be done. Very easy.

Now, using CI, I have the config files that have to change depending on what environment the code is working in, so it's kinda a pain in the ass to edit those config files every time you upload (or synchronize to remote).

I'm just curious how others who work locally then push to a remote server have their environments set up. Maybe someone has an easier way to handle things.

Thanks.
#2

[eluser]adamp1[/eluser]
Using phpED, I have a project file and directory for each thing I work on. The actual files are stored in the root of my local web server running off my PC. Therefore I can just fire up a browser and run the code. These files are also checkouts to svn repositories which means I can work on the files fully testing them but only then update and export my code (I.e not the base files).

Any config files I use while in development have special features to detect if its running on local and thus change the settings to those required.

I have to say I only do it this way since I only work on my own and not a full time web developer. Only do it on the side.
#3

[eluser]GSV Sleeper Service[/eluser]
hi,

there's two of us currently developing our first big CI app. setup is -

two environments - dev & live
two separate config files for each server - named config_dev.php & config_live.php, config.php at the moment just contains something along the lines of
Code:
if($_SERVER['HTTP_HOST'] == "dev_server_name"){
    include('config_dev.php');
} else {
    include('config_live.php');
}
the CI 'application' folder is under svn control, when we're happy that new code is working ok it's a simple matter of just running 'svn update' on the live server.

[edit] the same method above applies to config/database.php
#4

[eluser]jleequeen[/eluser]
@GSV Sleeper Service

That's a pretty neat solution to the problem. I hadn't thought of doing that with the config files. Thanks for the insight.
#5

[eluser]MadZad[/eluser]
We use the same idea as GSV Sleeper Service, but with a few other wrinkles you might be interested in.

I believe the $_SERVER global can be spoofed, so we use php_uname("n") instead.

We have developers working on their local machines, an integrated dev environment, and production. So, in addition to selecting a config file based on what machine we're on, I also check for the existence of a config_local.php in the same directory. That file would contain paths specific to my machine and would not be in version control or on the dev/prod servers. We do find it easier to put all our dev/prod defines inside the "if" statement instead of including different files like GSV, but that's just preference/situation - neither is better.

As always, keep ALL of your code outside of the webroot. CI makes this easy, and the only things you need inside the webroot are the index.php, css/images/js and some path configuration (to find the rest of the code).
#6

[eluser]GSV Sleeper Service[/eluser]
@MadZad - I'd never heard of php_uname before, but does php_uname('n') only return whatever 'hostname' on the OS is set to? if so, it's next to useless when using virtual hosts.

Do you have any evidence of the $_SERVER global being spoofed?

Also, good call about keeping all your code out of the webroot, I was surprised to see that the default CI install keeps everything inside the webroot.

[edit] - upon further investigation, php_uname('n') does return whatever the system hostname is set to.
#7

[eluser]Pygon[/eluser]
MadZad: The actual $_SERVER variable cannot be spoofed, but any items obtained from the client should be considered unreliable as the user-client can spoof its header values. $_SERVER['SERVER_NAME'] is obtained from the server, not the client, so this is reliable.

The following are unreliable:
HTTP_ACCEPT, HTTP_ACCEPT_CHARSET, HTTP_ACCEPT_ENCODING, HTTP_ACCEPT_LANGUAGE, HTTP_CONNECTION, HTTP_HOST, HTTP_REFERER, HTTP_USER_AGENT, REMOTE_ADDR, REMOTE_HOST, and REMOTE_PORT

GSV:
php_uname is reliable for determining the server OS registered hostname, but not the hostname provided by the webserver (such as a virtualhost).
#8

[eluser]MadZad[/eluser]
@Pygon - thanks for the info

We can use php_uname because we only care about what physical machine the code is running on. Not necessarily a solution for virtual servers, or any situation where you have different environments running on the same machine.
#9

[eluser]Pygon[/eluser]
No problem.

-- to the OP --

We mostly run linux so I prefer to use symbolic links, however as an alternative, the same can be done using includes, but i prefer to simply move my config directoy (the only thing that changes server to server) outside the application folder.

for example -- replacing each config with the simple line:
Code:
<? include( substr(APP_PATH,0,-1).'_config/'.basename(__FILE__) ); ?>

will give you a nice redirect -- just put your application configs in a folder called application_config (where "application" changes with your application folder name).
For example:
app1/
app1_config/
my_app/
my_app_config/
superduperdeluxe/
superduperdeluxe_config/

Makes uploading your application directories a breeze and there is no need to try to determine what to do according to the server name.
#10

[eluser]jleequeen[/eluser]
@Pygon

Thanks for the info. I have decided to use your suggestion of php_uname and instead of an if, I have used a switch statement since I read that it was faster than if statements.




Theme © iAndrew 2016 - Forum software by © MyBB