0

I would like to know your opinion about my setup right now, how I do things with SVN and if you could find some better solution for me. I'd appreciate it very much if someone could come up with some better solutions for my problems. I would like to do it the best way possible and the most efficiently.

My situation is as follows: I'm maintaining a PHP website which is connected to mysql database. I have a subdomain on which I'm testing everything. There are also two databases: first for testing purposes, second for the production server. I have a project in Netbeans and I'm connected to ftp with it so every change I make is directly transferred to the website. Also I'm connected to SVN server and the testing part of the website is in trunk directory. Every time I want to upload the changes to the server I'm commiting my trunk and then I'm copying it to tags. After that I got another project in Netbeans prepared, already connected to the same SVN, but to the last tag copy. After I copy the trunk to tag directory, I switch to the second project and switch to the newest version in tags. Now I have in some another directory every configuration file prepared in proper directory structure - I copy it to my production project. After that I click "Run" in Netbeans and that opens a window which allows me to accept the transfers to the sftp, but this time to the production part of the website.

My question is: is it the best way? Aren't there any more intuitive tools or options in SVN, so I don't have to copy the configuration files every time?

closed as primarily opinion-based by durron597, user22815, Ixrec, user40980, GlenH7 Sep 16 '15 at 20:43

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Where are you copying the configuration files? The configuration files should simply exist in the relevant environments. And I don't see in the whole description where they can't. Of course you have to distinguish which configuration items are environment-specific and which control the application logic and have them split accordingly between configuration on the environment and a versioned configuration. The environment usually only specifies domain and database connection and so you shouldn't need to touch it after initial setup. – Jan Hudec Aug 6 '13 at 14:52
  • Well I don't really know then how to solve it, because there are different configurations for test and for production server. And when I copy to tag I copy with configurations from the test server (I needed those so I could see how it works online, before releasing) – Kelu Thatsall Aug 6 '13 at 14:57
  • 1
    The environment-specific configurations should be about 4 lines long and not versioned (ok, they may be versioned as part of the system configuration of the server if your admin is into that, but definitely not as part of the project). Because they make absolutely zero sense outside of the current installation of the respective server. If they are more than 4 or so lines, you are doing it wrong. – Jan Hudec Aug 6 '13 at 15:00
  • I have 3 configuration files, also except database connection (in 2 files, one for admin, one for users), there are settings like if it's https or not (test server isn't secure configured - our host provider doesn't allow that). Also there are different .htaccess files for test and for realese. This is a 10-year old version of osCommerce, I cannot do much about that... I know it's not perfect. I recently started working on it and I'm trying to make it a little better, but it's not easy ;) – Kelu Thatsall Aug 6 '13 at 15:06
  • That does not look that bad. The things you mention are environment-specific. Unless the .htaccess specifies things like files that live under web root, but should not actually be accessible at all (i.e. authentication domains and methods are environment-specific), in which case you should aim for moving them out of there (the usual way is to create symlink in www root pointing to subdirectory of the deployment directory; .. resolves according to physical layout and web server eliminates .. in URL before accessing the filesystem, so it won't ever get to them). – Jan Hudec Aug 6 '13 at 15:18
3

A software package has two kinds of configuration:

  1. environment-specific configuration
  2. behaviour-specific configuration

The former differs between the devel, test, stage and production environments. It should have at most 4 lines or so (web server base url, database connection string, SSL certificates, connection strings/urls to other related components, installation directory, authentication realm and such; you rarely need most of those even) and since it makes absolutely zero sense outside this installation on the particular server (i.e. it may change when the server is reinstalled), it should generally not be versioned (except as part of versioning the server installation if your admin is into that).

The later should be versioned all right, but must not differ between the environments. It's just part of the source/build.

Obviously the configuration needs to be appopriately split across two files so you can version the one you need and not the other one.

  • Okay, I get it. Thanks for the advice, but I don't know how exactly do I manage to do that? How do I NOT version a configuration file? Should I just keep it server-side and delete it locally so it doesn't get versioned by SVN? – Kelu Thatsall Aug 6 '13 at 15:09
  • What about database items ids? What about base url? What about allowed ips? What about... many things can be environment specific. – Florian Margaine Aug 6 '13 at 15:15
  • 1
    @KeluThatsall: The file either should only exist on the relevant servers and not locally at all, or you can simply add it in the subversion's ignore property and not add it as versioned and it will not version it. – Jan Hudec Aug 6 '13 at 15:20
  • @FlorianMargaine: base url or web server name or whatever. Yes, allowed IPs and authentication method and authentication domain and stuff, sure. In most applications it still won't be very long. And most of it will even not be part of the application itself, but e.g. of apache config. – Jan Hudec Aug 6 '13 at 15:24
  • Okay, I'll try putting it only serverside and delete it locally for now :) It seems it will be fine. – Kelu Thatsall Aug 6 '13 at 15:24
3

A simple solution would be to keep all the configuration files in the repo and the have a build script that copies the correct version for the environment in when needed.

  • Okay, but how do I write such script, and how do I keep it in repo? Do you think about command line script to just copy? How do I copy only some exact files within a repository? – Kelu Thatsall Aug 6 '13 at 15:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.