I have a home headless server for dev+testing.For small projects my workflow is just drag throught sftp several files to a temp folder on my workmachine and then upload them to the "production" server. But now I face a big project that dapends on the release files has no changes. Production server is a shared hosting with apache. I don't want to waste time neither bandwidth. Seems that a revision control software could suit the purpose. But i can't install software above apache. What could the workflow be? Is there any "subversion","git", (...) for web deployement?Any other solution?
Thanks in advance
You need ssh (or direct) access to do this(svn or git deploy) but you can use phing deployment and composer for the dependencies.
https://github.com/composer/composer
http://www.phing.info/trac/
You can use rsync the same way you use sftp (obviusly, the server has to support it) and is instantaneos for something like 65000 files (wen only maybe 2 have changed).
Something like GIT or SVN can be much better, and have other features, but if you want something simple, and you are a single dev, you can use a backup system + rsync + a diff tool like Meld or WinMerge.
Possible workflow:
You develop in workstation A, in folder "dev/".
You review changes, and transfer changes with diff/winmerge to folder "rc/".
You upload "rc/" to "public_html/" in the public server with rsync.
Wen you copy changes from "dev/" to "rc/" you re-read then, and check if make sense, only transfering the changes that make sense and don't make rc/ unstable. If all changes are safe, you can do it just a single button.
This is a inferior system to using something based on git/svn.
VCS-systems and Deploy-systems are, really, different classes for different jobs and tasks. You have to ask, "How to deploy web application", I think.
Phing already was recommended, from other side you can (using tools of your SCM, if any used) export changed files after each changeset and transfer on shared hosting using any available transport. Can't see problem here.
For small projects my workflow is just drag throught sftp several
files to a temp folder on my workmachine and then upload them to the
"production" server
is perfectly applicable to big projects also
Related
I am developing (solo web developer) a rather large web based system which needs to run at various different locations. Unfortunately, due to some clients having dialup, we have had to do this and not have a central server for them all. Each client is part of our VPN, and those on dialup/ISDN get dialed on demand from our Cisco router. All clients are accessable within a matter of seconds.
I was wondering what the best way to release an update to all these clients at once would be. Automation would be great as their are 23+ locations to deploy the system to, each of which is used on a very regular basis. Because of this, when deploying, I need to display a 'updating' page so that the clients don't try access the system while the update is partially complete.
Any thoughts on what would be the best solution
EDIT: Found FileSyncTask which allows me to rsync with Phing. Going to use that.
There's also a case here for maintaining a "master" code repository (in SVN, CVS or maybe GIT). This isn't your standard "keep editions of your code in the repo and allow roll backs"... this repo holds your current production code (only). Once an update is ready you check the working updated code into the master repo. All of your servers check the repo on a scheduled bases to see if it's changed, downloading new code if a change is found. That check process could even include turning on the maintenance.php file (that symcbean suggested) before starting the repo download and removing the file once the download is complete.
At the company I work for, we work with huge web-based systems which are both Java and PHP. For all systems we have our development environments and production environments.
This company has over 200 developers, so I guess you can imagine the size of the products we develop.
What we have done is use ANT and RPM build archives for creating deployment packages. This is done quite easily. I haven't done this myself, but might be worth for you to look into.
Because we use Linux systems we can easily deploy RPM packages, the setup scripts within a RPM package can make sure everything gets to the correct place. Also you get a more proper version handling and release process.
Hope this helped you.
Br,
Paul
There's 2 parts to this, lets deal with the simple one first:
I need to display a 'updating' page
If you need to disable the entire site while maintaining transactional integrity, and publishing a message to the users from the server being updated, then the only practical way to do this is via an auto-prepend - this needs to be configured in advance (note - I believe this can be done using a .htaccess file without having to restart the webserver for a new PHP config):
<?php
if (file_exists($_SERVER['DOCUMENT_ROOT'] . '/maintenance.php')) {
include_once($_SERVER['DOCUMENT_ROOT'] . '/maintenance.php');
exit;
}
Then just drop maintenance.php into your webroot and that file will be displayed instead of the expected file. Note that it should probably include a session_start() and auto-refresh to ensure the session is not expired. You might want to extend the above to allow a grace period where POSTs will still be processed e.g. by adding a second php file.
In terms of deploying to remote sites, I'd recommend using rsync over ssh for copying content files - which should be invoked via a controlling script which:
Applies the lock file(s) as shown above
runs rsync to replicate files
runs any database deployment script
removes the lock file(s)
If each site has a different set up then I'd recommend either managing the site specific stuff via a hierarchy of include paths, or even maintaining a comlpete image of each site locally.
C.
Would it be quicker to make wordpress theme direct on FTP? Because client want to see the progress and if I will work on local XAMPP then it would not be possible to update any changes quickly.
How to setup theme development environment with any free and lightweight IDE for windows XP?
Sounds like you're not considering the benefits of using Revision Control. if you're not using it, change your workflow so you can. It will make your development much more secure. Working with a local copy of code will make using revision control an easier goal.
On windows, mercurial is probably a good bet, or its simple wrapping program, tortoisehg.
You want to be able to make changes fast and not have to worry about whether you can roll them back. to me that says "use a locally running development copy, use source control, and take the short time to upload a finished point in time to the server."
Fast development, a secure change history, and never having to wonder whether your code is backed up: local development, with source control.
You have a lot of choises:
A plugin for your IDE to automatically upload your saved files to FTP.
Open your local server to the world using something like no-ip and few router configurations.
The least AND the worse, edit your files via FTP as you said using some FTP Client that allows it like Smart FTP (paid) or FileZilla (free).
All options should work... But for gods sake, don't upload to production server! Always keep an development server to test the things before uploading do production machine. This is safer to you and you client, trust me.
A great free (and heavy) IDE for Windows, MAC and UNIX is the Eclipse.
A lightweight and free IDE for Windows is Notepad++.
You can save urself lot of trouble by installing a plugin called theme test drive.
Basically, only the people logged in as admins can see the new on-going theme as it is being developped.
Visitors will have their regular view
You can edit the theme directly then on the live website for your manager to see
( this is an alternative solution to solve ur problem)
synchronizing theme files via FTP should not be a problem since each file is only a couple of KB. so if ur editing locally, u can re-upload when ur admin wants to see
I'm starting to use SVN repositories for all of our websites and wanted to know what the best practise was regarding website config files.
Should they be stored in the repository? The problem is the configuration of the websites need to be different for the working copies than that of the live sites. If I edit the config file for a working copy so that I can test on my machine when I commit back to the repository the config file will be updated there too and could then potentially get uploaded to the live site.
What do people generally do with config files, is there a way to tell SVN to skip config files when performing commits etc?
Generally, it's best to put config files into version control if they store significant information.
If you're talking ASP.NET sites here, I'd definitely place the config file in SVN. You can play a few tricks in ASP.NET config files using inheritInChildApplications and allowOverride (see How to: Lock ASP.NET Configuration Settings) which may allow you to force a local debug version to use different settings from the final production version despite using the same config file: just mount the website as a sub-directory in the local debug IIS and lock a few sections you wish to override. And of course, you could just include two config keys for particularly tricky bits and check in code which to load.
In general, it's good practice to make deploying anything from SVN a process involving as few manual steps as possible. That makes it more likely you'll do it correctly under time-pressure, and it makes disaster recovery easier to boot (say, when your datacenter springs a leak and you want to install the web site on some temporary box until you've got those backups sorted). Ideally, an svn checkout or export with at most a compile should suffice to get the web site up and running. I include even binary dll-dependencies directly in svn (stuff like javascript compressors and whatnot) so it'll run without requiring a bunch of custom library installs on the server, and compile on a dev machine with just msbuild.
For PHP, the principle is the same. However, you'll need different tricks. For instance, you might write the config file such that it checks some global system environment variable, and then overrides selected settings if it's a dev-machine. For instance, I've a setup similar to this where I check the IP address; all dev-machines are in a particular IP-block; unless a machine is in that IP block, it's considered a production machine (which doesn't enable various tracing etc. options). You could also check the host name, or simply any old environment variable which all developers agree to set on their development machines.
I think its best to keep config files in SVN. Regarding settings for staging/production environment, what we do is to have seperate config files for each environment, and then swap them out as part of our build process (using Ant and MSBuild). I.e. we can trigger a "production build", which will copy the production web.config file.
I would have the file in version control, absolutely, as it's generally pivotal to the function of the site. To stop it getting loaded to live, you could look at a build script (e.g. Web Deployment Project), which would switch out your development versions of the configuration with a 'live' version.
Sorry, ignore the link, just saw your comment about this being a PHP site - principle is the same however.
If the variables between your dev/live environments are limited to just connecionstrings and appsettings, then you can split your web.config into seperate files, and have a different file loaded in for each environment. That way, you can check everything into SVN and just update the filename reference in your webconfig depending on which environment you are deploying to.
http://kartones.net/blogs/kartones/archive/2009/09/29/asp-net-split-appsettings-and-connectionstrings-to-separate-files.aspx
Edit: Just seen you're talking about PHP.
In general the best-practice is to store all the custom configuration files under version control. You may want to keep a separate config file for the production and development versions.
If possible, try to extract all the config sections that depend on the deployment environment (connection strings, paths, etc) into separate files. Then link to them from the main (common) config file, so that it will be just a matter of updating the reference when you change your environment from development to production.
I have a rather large php project with all kinds of different third party includes. Its all managed with Netbeans PHP. I have a few problems i would like some oppinions on.
Does anyone build there php-project? When i upload to server via ftp i get all kinds of project files which doesnt belong to live environment.
Would be nice if a build solution could encode all files when building (actually copying files to new location and leaving out project files and files like that).
Let me hear how you handle your php projects (development, test, build/deploy) with OS X.
Thanks
Well you could write a shell (or scripting language of your choice) script to selectively copy the files you want to your remote server.
Alternately, you could put the code to be published (again, leaving out the undesired files) into a version control system (git, svn, etc) and pull the code to the remote machine that way. There are lots of other benefits of using VCS as well.
You could also use something like ant to write a "build" script which does any manipulation needed for deployment.
I use Eclipse PDT and mount server with Macfusion. Eclipse File Sync plugin then syncs everytihing to mounted drive (can exclude unwanted files/directories).
Also using a SVN and opening project directly from remote drive with Eclipse and including libraries from project properties. So there is two projects - one for local development and other is live in server - syncronized with SVN
(Eclipse plugin Clay for database diagrams is awsome too)
Though I am not an OSX user I am a Mac-in-the know. Basically I get invited to their house parties and politely decline to run amok with Windows and Linux/Unix (who is OSX's older sister, it is all so very confusing). In any case, Mac adds extra files to everything. I know when a designer is using a mac vs a pc. I get extra files and directories in their attachments if there is a folder. As far as project files, there needs to be a way to set up netbeans to keep the files for project in a different location from your working on files. If not then shame on your IDE. Well, if nothing works, since Linux/Unix is close to my heart I can write a script for you to pull all files of a list of extensions out and copy them to a new directory with subfolders in tact. Here ya are:
This should work
find . -name '*.php' | xargs rsync -avuzb '{}' exportdirectory/
I do not have a machine to test it on right now and Cygwin, for all it's effort just fails sometimes. Let me know how it goes, otherwise use Unix wizardy :D Because yes, as we know OSX uses Unix command line. The crude script is mainly to give you an idea of a way you can do it. I am sure there is php, html, css, js, and other files and on rare occasion (god lets hope not) just knowing extensions isn't going to be enough.
Personally I use gvim and refuse to use project managers, I use gvim and command line and though I have used both, I am highly preferential to the current way I am doing everything. Hey, it's a choice though. No criticism here if you walk another journey.
At my company we have a group of 8 web developers for our business web site (entirely written in PHP, but that shouldn't matter). Everyone in the group is working on different projects at the same time and whenever they're done with their task, they immediately deploy it (cause business is moving fast these days).
Currently the development happens on one shared server with all developers working on the same code base (using RCS to "lock" files away from others). When deployment is due, the changed files are copied over to a "staging" server and then a sync script uploads the files to our main webserver from where it is distributed over to the other 9 servers.
Quite happily, the web dev team asked us for help in order to improve the process (after us complaining for a while) and now our idea for setting up their dev environment is as follows:
A dev server with virtual directories, so that everybody has their own codebase,
SVN (or any other VCS) to keep track of changes
a central server for testing holding the latest checked in code
The question is now: How do we manage to deploy the changed files on to the server without accidentaly uploading bugs from other projects? My first idea was to simply export the latest revision from the repository, but that would not give full control over the files.
How do you manage such a situation? What kind of deployment scripts do you have in action?
(As a special challenge: the website has organically grown over the last 10 years, so the projects are not split up in small chunks, but files for one specific feature are spread all over the directory tree.)
Cassy - you obviously have a long way to go before you'll get your source code management entirely in order, but it sounds like you are on your way!
Having individual sandboxes will definitely help on things. Next then make sure that the website is ALWAYS just a clean checkout of a particular revision, tag or branch from subversion.
We use git, but we have a similar setup. We tag a particular version with a version number (in git we also get to add a description to the tag; good for release notes!) and then we have a script that anyone with access to "do a release" can run that takes two parameters -- which system is going to be updated (the datacenter and if we're updating the test or the production server) and then the version number (the tag).
The script uses sudo to then run the release script in a shared account. It does a checkout of the relevant version, minimizes javascript and CSS1, pushes the code to the relevant servers for the environment and then restarts what needs to be restarted. The last line of the release script connects to one of the webservers and tails the error log.
On our websites we include an html comment at the bottom of each page with the current server name and the version -- makes it easy to see "What's running right now?"
1 and a bunch of other housekeeping tasks like that...
You should consider using branching and merging for individual projects (on the same codebase), if they make huge changes to the shared codebase.
we usually have a local dev enviroment for testing (meaning, webserver locally) for testing the uncommited code (you don't want to commit non functioning code at all), but that dev enviroment could even be on a separeate server using shared folders.
however, committed code, should be deployed to a staging server for testing before putting it in production.
You can probably use Capistrano even though is more for ruby there are some articles that describe how to use it for PHP
I think Phing can be use with CVS but not with SVN (at least that what I last read)
There are also some project around that mimic Capistrano but written in PHP.
Otherwise there is also a custom made solution :
tag files you want to deploy.
checkout files using the tag in a
specific directory
symlink the directory to the current
document root (easy to rollback to
the previous version)
Naturally check out SVN for the repository, Trac to track things, and Apache Ant to deploy.
The basic process is managing in Subversion, tracking the repositroy and developers in Trac and using Ant deployment scripts to push your site out with the settings needed. Ant allows you to easily deploy a project to a specific location. (Dev/test/prod) etc.
You need to look at:
Continuous Integration
Running unit tests on check-in of code to check it is bug free
Potentially rejecting code if it contains a bug
Having nightly builds
Releasing only the last build that was bug free
You may not get to a perfect solution, especially not at first, but the more you use your chosen solution, the more comfortable everyone will get and be able to make suggestions on improving it.
We check for the stability with ant, every night. And use ant script to deploy. It is very easy to configure and use.
I gave a similar answer yesterday to another question. Basically you can work in branches and integrate before going live.
The biggest thing you will have to get your head round is that you are dealing with changes to files, rather than individual files. Once you have branches there isn't really a current version there are just versions with different changes in.