I ask here as this kind of question would most likely be closed on SO...<p>Recently I have been setting up my own development environment using git and Jenkins. I have so far managed to initiate build and test upon committing. Now the final step is to deploy to the web server.<p>I don't have a single .war file or similar. I have hundreds of small files like graphics, php files, js files for node and apache configuration files.<p>I keep almost everything in git but I do not want everything pushed to the web. My initial thought was to just zip a folder, upload it and unzip. But this requires me to keep some sort of list for the files which are used in production and those who are not (like reference images or modules which are temp. disabled).<p>1)
Both the js files and the php files have require directives which would let me derive which files to include. Images are referenced as well so these I could also get. Putting code together for this is however pretty time consuming so maybe one of you clever guys (and girls) could give me a pointer about where to begin?<p>2)
How do I go about replicating/syncing DB changes from the beta DB to the production DB? I am using postgres and don't have very much experience with DBA.
If you're living inside the PHP world, I'd take a look at Phing ( <a href="http://www.phing.info/trac/" rel="nofollow">http://www.phing.info/trac/</a> ). It's very similar to Apache Ant and uses a XML file to describe the build tasks (include/exclude files, copy, tar, SCP, run PHPUnit tests, etc.) and can easily be extended using PHP (we use the rsync extension). It takes a little while to get everything up and running, but once you've got it (and well tests) it'd pretty much bulletproof.<p>Also worth taking a look at WePay's blog post on how they do deployments: <a href="http://blog.wepay.com/2010/11/30/weploy-wepays-deployment-tool/" rel="nofollow">http://blog.wepay.com/2010/11/30/weploy-wepays-deployment-to...</a>
I deploy a simple project of mine using a horrible PHP script I wrote: <a href="https://github.etsycorp.com/gist/391780" rel="nofollow">https://github.etsycorp.com/gist/391780</a><p>My site is just static files, but it wouldn't actually be that much more complicated if it wasn't. The only thing I'd really need to add would be a line that runs database migrations. You can google "PHP database migrations" to find a handful of libraries that do this, or honestly just make a dummy rails project, and use theirs: <a href="http://guides.rubyonrails.org/migrations.html" rel="nofollow">http://guides.rubyonrails.org/migrations.html</a>.<p>Note that the script I wrote is for a site of mine that gets literally zero traffic (although I'm hoping to get more to it eventually.) If it was something more important, I would probably start moving in the direction of Chef or Capistrano, which are more structured, and have things like error-handling.<p>Regarding stuff you don't want pushed to the site, it sounds like you need to fix your directory structure. It should be something like this:<p><pre><code> project/
..app/
....controller.php
....database.php [etc]
..public/
....index.php
....images/
......some_img.jpeg
....css/
......styles.css
</code></pre>
and then the only directory that should be accessible from the internets is project/public. You deploy the project dir, and serve the site from project/public (so if I go to project.com/index.php, that corresponds to project/public/index.php on the file system.)<p>If you have multiple apps in one repo, you would just have them under project1, project2, then follow the same structure. If you have stuff that doesn't get deployed, it could sit alongside project in a different directory that you don't deploy.<p>For your requires and so on, you should be using relative paths, so that shouldn't be a problem. If you're not using relative paths, you're crazy and you should fix that. (First the being crazy part, then the relative paths part. You should also use an autoloader, so that you're not really manually requiring stuff that much.
My tip for using Jenkins (or CI in general): have your build script produce a single-file artifact. You don't have a .war file, but what you can do is simply tar or zip your project. I recommend having a source directory and a build directory, and writing your build script such that the source directory is untouched and the output files are placed in the build directory. At the end, zip up that build directory and call it your artifact. You don't HAVE to do this but that's my piece of advice.. it will make your life easier.<p>Once you've got a stable artifact-builder, you can write a nice script that takes that file and deploys it to the location of your choice.<p>As you point out, some work needs to be done to determine which files are copied in the build process. I'm not familiar with PHP, but I am involved in an HTML application that has a similar need. We're using RequireJS <<a href="http://requirejs.org/docs/optimization.html#wholeproject>" rel="nofollow">http://requirejs.org/docs/optimization.html#wholeproject>...</a>, which has the ability to do all of the copying and optimization in one step. In our build.js file, we specify some patterns to control which files are included and excluded.
Do you know of ServerFault? The reason you shouldn't ask this on StackOverflow is that it is on-topic on sister-site ServerFault. Either you'll find a similar question, or you'll have the opportunity to ask yours.