Hi,
I’m just wondering if there is a guide somewhere or any advice on best practices for setting up a hosting environment while working on development of a site.
We do CMS sites (Joomla & Wordpress) and just want some good pointers for things to watch for to make a seamless development > launch process. We currently have a VPS hosting account that we will be putting sites on. We can add additional IP addresses if it’s simplest to give each site it’s own dedicated IP address.
Some things that are important:
Want to keep site root relative links the same as they will be when we transfer the domain so no crazy hoops to jump through (i.e., root not on subdirectory).
Want to be able to see SEF URLs when developing, using .htaccess file (minus actual domain, of course).
Want site to be easy to get to for all developers and client viewing and working on it simultaneously.
Want site to not be seen by general public (not indexed or searchable, etc.).
Would like to be able to install and test SSL certificates when required (for shopping carts, donations, etc.).
So what are some common and/or recommended workflows?
Yes, they used to, with Version 1, but not now with version 2. There is a demo site here where you can check out the control panel, but that doesn’t give you experience of what it’s like to set up templates and input fields, although you can download the templates from the page above.
Such a shared hosting environment is quite common and absolutely fine for such a small amount of websites. (Though the amount of sites is a poor measure of course, it’s about the traffic individual sites get. You could always move a couple of busy, high-traffic sites to a dedicated VPS later on though.)
I have my private hosting on a shared server with a CPanel, but have multiple domains and subdomains set up under my account.
The way it works is that you can have multiple virtual hosts on the one IP Address, the server will detect the host header and use the correct DocumentRoot for this.
e.g. example.com -> /home/username/domains/example.com staging.example.com -> /home/username/domains/staging.example.com
Ralph: I haven’t had a play with Expression Engine yet, I think I was going to take a look at it once upon a time to evaluate but they don’t seem to have any kind of trial version.
Thanks for the replies. Since we will mostly be hosting these sites on our VPS, and creating a new cPanel account for each, we were thinking it would be easier to NOT have to move/migrate everything over from a separate server/account that is just for development. We were thinking it is ‘safer’ and more efficient to just install and create the sites at the actual place they will live. The obvious exception to this is for clients who already have a website and want to keep their existing hosting solution (which doesn’t happen that often).
The biggest issue for us was having the development site be at ‘the root’ of whatever account it was on. With a CMS like Joomla or Wordpress, especially if you’re doing a lot of customization and/or testing SEF URLs, having the site not be on the root just adds potential to something not being updated properly when the site goes live.
So we were going to try to use a dedicated IP address for each site, allowing the development sites to be installed on the root of where they will eventually live. The switch to go live is then simply pointing the domain.
UNFORTUNATELY, we just found out from our host yesterday that due to the worldwide shortage of IPv4 addresses, they will only give them out now to people who have a SSL certificate. YIKES!
So it looks like every new site we add will share our root IP address. This is definitely not ideal, but I’m not sure what options we have. So the development sites will always be accessed by ‘http://ip.ad.dr.es.s/~accountname’ until the domain is switched over.
Any ideas how best to deal with this?
Any potential downfalls of all our clients’ sites (we’ll have up to 30 by years end) sharing the same IP address?
I use ExpressionEngine, but I must admit, I’ve just been reading about 2 plugins that apparently make it easy to track all the settings in the CMS and update them in one swipe: DeployHelper and REElocate. So I really can’t complain.
Unless clients want to update content themselves, I go for static sites. With a few PHP includes etc., I find it nicer to work that way, knowing what all the code is doing.
Hm, interesting reply. I no longer use WP, and haven’t found the ideal way to move the CMS I use. I know it can be done, but I so much prefer static sites at times like these.
Static sites can be nice and simple to deal with, every now and then. But anything that’s more than 5 pages that needs updating gets stuffed in to some kind of a CMS or templating system for me
I do it with pretty much everything that isn’t a 1-page site. Obviously if it doesn’t make sense to have a separate website set up, I’ll skip that step, this is an exception rather than a rule though.
At work, most apps/websites I work on tend to be bespoke .NET applications (where I am the front-end dev working with a team of .NET devs) so most of the time we don’t worry about changes to URLs because we’ll reference everything relative to the root.
With my personal projects I mostly use Wordpress, in which most of the customization lies in the themes and plugins, which are files easily migrated over. The only hassle with automagic wordpress database migrations is that Wordpress will store the “site_url” parameter, which is something in the form of “http://example.com”. However, if you only need to migrate content, you can easily export it using the Wordpress export/import tools. If you are doing a direct database migration it’s a simple matter of jumping in to phpMyAdmin and changing the value or you could write it as part of a migration script.
I’m currently in the process of trying to find a nice Continuous Integration (CI) solution for myself at home. Bamboo by Atlassian is looking like a good candidate.
CI is something I highly recommend, especially in a multi-developer environment. All that time you normally spend migrating sites, pushing things to staging or live environments, making config updates, copying and pasting files… CI will take care of these things for you (to a certain extent of course ;))
With most sites I work on I’ll have a “staging” version of the site, e.g. staging.example.com
This way you can set up your website and have it in a separate, sandboxed environment.
once you’re ready to go live, it’s a simple matter of copying the files and migrating the database.
You can even go so far as setting up a continuous integration service that will push changes to staging/ live for you when you check your code in to source control.
If using a CMS, you have to make sure URLs don’t set set in there that will break the site in aonther location. John, do you do this just with static sites, or with a CMS? If so, do you have to make any changes to URLs during migration? (and if not, what CMS is it?)
For myself I set up an local linux development server with open-source ispconfig3 server panel, which makes development server that pretty closely mirrors a hosted server.
Hi,
In our case, the different accounts will not be ‘subdomains’ of a common URL (such as your ‘example.com’ and ‘staging.example.com’.
The way our hosting is setup, each new cPanel account will use our shared IP address and it’s URL will be something like: http://shared.ip.add.ress/~cpanelaccount.
So this will not appear as a root like a subdomain type of URL might.
Anyone deal with something like this???
Any thoughts for how to keep the root relative linking and URLs smooth for development as well as for going live seamlessly???
Thanks for the response. I’m not sure that the site is actually ‘hosted’ on http://123.456.789.123/~username, but that is most definitely the URL of any new site before the real domain is pointed over. We use a Host Gator VPS solution.
And I’m not sure about ‘binding’ a cPanel account to a domain. We have to assign a unique domain to every cPanel account, but this is usually what the final site will end up being.
But in thinking about it, we could assign a ‘fake/test’ domain to these cPanel accounts while they are in development. So it might be ‘http://www.testdomain.com/’ while the site is in development. Then we would change the cPanel domain to the real domain when it’s time to go live.
But I would rather not purchase and manage 20-30 ‘test’ domains if I don’t have to.
Anyone know if there’s a way with WHM and/or cPanel to ‘assign’ or ‘direct’ separate subdomains to unique cPanel accounts??
So we could do ‘site1.testdomain.com’, ‘site2.testdomain.com’, etc. while in development, but have each of those resolve to a unique cPanel account (site)? I know how to add subdomains to a single cPanel account, but not ‘separate’ them out for multiple accounts.
Why are you worrying about CPanel at this stage? In these situations, I just build the site at subdomain.myownsite.com and then move the site to its final destination when the site is ready to go lve and the domain is ready to be redirected (if need be). At that time, you can set up the CPanel account etc. for the site. Is there any reason why you want CPanel set up in advance?
PS: if your client already has a site, it may be possible to build the site on the same server, right in the root folder. For example, a site I am redesigning at the moment has an existing site, but the home page is index.html, while the home page of the new site is index.php. So I can happily work on the site in situ but the public doesn’t see it at all at this stage, because the home page defaults to index.html.
We like setting up the cPanel account first so that everything is setup as it will be when final, including databases, FTP accounts, any .htaccess work, email accounts, etc. That way, once it’s time to go live we just flip the switch feeling VERY confident that everything has been tested and works well without the chance for anything getting messed up in a transfer.
But I found out we can assign cPanel accounts to separate subdomains in WHM when creating them, so this will probably be the simplest solution for us. We’ll just use ‘sitename.testsite.com’ while in development, and when it’s time to go live we only have to change the cPanel domain to ‘realsitename.com’ and point the domain at the regsitrar. Much less time involved and less chance for things to get messed up in a transfer.
Was just working on a project where I set up a CentOS VPS and developed the site, a booking system, using Ruby on Rails. I don’t have any control panel for the server, haven’t found it necessary to have one. I just set up the web server and have a Git SCM repository on that same VPS. As I do on most projects, I use Capistrano with “capistrano-ext” to be able to quickly deploy from the Git repo to the test site or the live site. A quick “cap deploy” would default to updating the test site with the latest changes.
The database I copied manually from test to live environment when the site was released since the content was added there while I was developing. From there on, test and live websites have different databases so we can test without messing up the live version. If the client needs to add something to test and migrate it to live (such as when a lot of information needs to be deployed fast, at once), I’ll just do it manually.
If I had a site dedicated to staging, populating content, I’d create a task for Capistrano to do the database migration when I ask it to. When I worked at an agency, we had a release manager for the code but always copied the databases manually for CMSs like Drupal—I believe we were working on something to solve that. Anyway, have also been playing with some Git hooks with shell scripts to do things like deploy to production, which also works well but may not be as simple to do as using a tool like Capistrano.
John mentioned Continuous Integration somewhere earlier in the thread, and that’s what I would focus on. If any of the sites will need their own IP or if you have need for cPanel or whatever, that’s up to you and depends on the site. But I’d say at this stage in development, Continuous Integration / deployment / source control is more important. I wouldn’t want to standardize this though, it all depends on the project. Prioritize using intuition.
