Good day Experts,
I need to implement subversion on our WordPress websites.
I have never worked with Subversion before. I have however read-up on it and understand the principles.
We have a Development environment consisting of only one server hosting multiple (about 10) WordPress websites. Then we have a Production Environment that consist of 2 servers, one hosting only the WordPress Files, and the other hosting the WordPress databases. The production Environment is the live environment and we want to completely stray away from making any changes directly on here before it has not been tested via the Development Environment.
I need to implement subversion to basically track the changes on the development environment (obviously with functionality to roll back to a previous version if something goes wrong) and then to make it quick and easy for the team to publish to the Production Environment without having to use FTP – may I add that the sites is about 6GB in size on average. Also as it is the design and development team that is going to work with this it would be nice to have a GUI to work from. (I think they are going to give me grey hair if I need to train them on using console commands.)
Our hosting provider supports SVN and Git. I only have been looking at Git and like I said I understand the principles.
But what I cannot get my head around is how to implement this in our environment. Keeping in mind that this is WordPress Websites and that the Production Environment consist of 2 different servers. Like how do I push the database over to the production environment to a different server than the files?
Sorry if this is maybe stupid questions, but like I said I have never worked with any form of subversion before.
If anyone can send me in the right direction on how I could implement this. It would really be much appreciated.
Thanks in advance.
Related
I'm very new to Drupal, so please don't be too mad in case I have any major misunderstandings :) I've tried searching for a similar problem, but is just couldn't find a suitable solution for my case.
We're currently setting up a Drupal 9 project, which will perspectively have a shared development environment and a production environment as well as a local instance to develop on. I'd wish to have a way to synchronize those instances to have the same configuration, content types and optionally even content.
At the moment, I'm developing a theme locally, which means I have installed a Drupal instance inside a XAMPP server. That theme is versioned by git, so it is migratable to another developer without a problem.
For migrating the structure and content (which is obviously saved in the database), I tried using Backup & Migrate, but there were two issues I was facing: The D9 version is not fully supported yet, so an installation via composer fails with default security settings, and there seems to be an already multiple times reported bug when trying to backup the entire site. You can workaround it by backing up the database and the files separately, but this is pretty inconvenient due to other issues (but let's keep it a little short...).
I also tried to export the whole database, which is actually working (after this little fix), but the overhead seems a little high for me. Especially when I just want to copy new content types from dev to prod environment without users, content and so on, for instance.
So, to finally come to an end, is there any best practice for this case? Or should I even consider to go a whole other way?
Thanks in advance!
I definitely wouldn't recommend using Backup & Migrate for this - that's so Drupal 7! Drupal 9 has better tools that are baked into core!
There are many possible ways to import/export Config and Content entities across environments, but I'll share what I believe to be the current best practices.
For Configuration, Drupal 9 has a built-in Configuration Management system that makes it quite easy to migrate Config across environments. It can be used within the Drupal UI, and also integrates with Drush (a command-line tool for Drupal).
Essentially, the Config system exports all Config settings as standardized YAML files, which can easily be included in your Git repository. This will make it incredibly easy to set up another Drupal environment that is identical in its Config settings.
More info on Configuration Management can be found here.
For Content, Drupal 9 has a built-in Migrate API, which facilitates migrations from any data source into a Drupal 9 environment. That means you could set up a migration that would allow you to migrate your Content entities across environments.
I've only ever used this for migrating Content (migrated from Drupal 7), but I believe it's also possible to use this to migrate Config as well.
If you decide to use the Migrate API, you may (depending on the setup of your content) need to install Migrate Tools and Migrate Plus.
More info on the Migrate API can be found here.
I would like to develop a website for a company with a lot of different functions. I decided to use the Symfony 2.0 framework for the first time and started reading the documentation and also a video tutorial.
After a week reading the documentation I still have some general questions unanswered. It would be great if you could help me with them:
Which client OS do you recommend to work with Symfony2? Windows doesn't seam appropriate.
Can I develop the whole website on a local Apache server and than upload the files to a regular webhosting server and use it?
I bought a regular web hosting (www.cyon.ch) is this recommended? I can't use any console on it.
I'm really confused and I'm sure I'm asking quite some stupid questions. It would be great if you can help me understand better how Symfony2 works.
Thanks in advance!
Windows is OK, as long as you have PHP and MySQL. There are several package that can do the job.
You can. In fact you should. Common workflow is develop on localhost and test on test server, and then move to production server. You should use a SCM like git.
Theoretically you can. But you won't have access to many console features that are really useful, like updating the database schema, flushing cache, download dependecies automatically, etc. I know some people doing this (copying everything with vendors), that's heavy and insecure.
When it takes half a day to update the app, you don't hurry when you have to apply security patch. Unlike Wordpress or Drupal, Symfony has no other 'easy way' to update vendors and third party modules than command line interface. So it is really not a good idea. You can find a lot of VPS with full ssh access, that cost less than 10$ months.
I work on windows just fine. For wamp server, use Easyphp. Everything is easy to configure and most important; cli and apache users use same php.ini
Yes, but it is bad. You should use either svn or git. I find svn easier to use and both of them have UI variants: TortoiseSVN and TortoiseGIT.
No. You need console access and php5.3 minimum.
I develop on a local machine a Wordpress site and I'm now looking for a mechanism to deploy it easy and fast. I'm thinking about a DEV environment (located on my local machine), a STAGING environment (a subdomain on the client page, maybe staging.example.com) and of course a LIVE environment (example.com)!
My current workaround:
As I work with Aptana I'm able to sync my changed files with the deploy mechanism the IDE provides. Exporting my local database, finding/replacing the permalinks and importing the whole thing - finish! To deploy live, I have to replace all staging files with the live files.
This should be easier! Is there anyone out there, having a better workflow?
I'm open and really excited about your ideas!
Thanks a lot
greetings
Yep, it's frustrating and completely insane that Wordpress requires this process because they put absolute urls in the database. I develop in a similar fashion using multiple staging sites for qa and client review. After my first deployment with Wordpress I almost gave up on the platform entirely. All of the solutions recommended by core developers and others simply didn't work.
So I wrote a plugin: http://wordpress.org/extend/plugins/root-relative-urls/
that fixes the problem. With this plugin you don't need to do a search & replace on your content. No hosts file hacks, or dns tricks. With my plugin you can access the site via IP address or Computername or any type of forwarded host. And since it converts urls to root relative before they enter the database, you won't have to worry about them working between the different domain formats. And since they don't hard-code the scheme (http/s) in the url you won't have to worry about the 520 or so bugs that were reported in the wordpress trac database if you use SSL.
It's a staple for any wordpress project I work on these days. And I have written a couple other plugins to deal with idiosyncrasies that exist in the platform that you can check out here: http://wordpress.org/extend/plugins/profile/marcuspope
Hope that answers your problem.
I use Capistrano https://github.com/capistrano/capistrano/wiki/ for all my deployment needs and it is really good solution. You can simply script anything and it just works.
It could work for your deployment scheme too.
I also use Capistrano for both WordPress and Drupal deployments. I typically install modules locally for testing then push to test and production environments. For uploads, etc. I add custom tasks to manage syncing files stored in scm and those that are not. Here is a simple guide I put together.
http://www.celerify.com/deploy-wordpress-drupal-using-capistrano
I really like drupal somehow. But what disturbs me most is that i can't figure out a clear way of deployment. Drupal stores a lot of stuff inside the database (views, cck, workflow, trigger etc) that needs to be updated.
I've seen some modules that could be used for this task (eg features) and I'm not sure if they are sufficient. Yet they are only for drupal6 and i currently have to work on a drupal5 site where updating is not yet an option.
Any ideas?
This is a weakness. Drupal doesn't have the developer tools built in that make development and deployment easy like Rails does (for example). One problem is Drupal isn't aware of it's environment natively. Secondly, there are too many different methods and modules that require special care. It can get very confusing. But things are getting better with drush and drush make.
I'm assuming here that you have a development environment on your local machine and a live or staging server you upload to.
The first thing you have to do is work out how to get your database fixture and your code to and from your server to your development environment very quickly. You need to make this proceedure as painless as possible so you can keep different versions of your site in sync without much effort. This will mean you will hopefully be able to manage less change every time you deploy. Hopefully...
Moving the database around isn't too hard. You could use phpMyadmin or mysqldump but the backup migrate module is my favorite tool.
To upload code from your local repository or site can be done in a few ways. If you use a version control system like git, you can commit on your local machine and check out again on the staging server. There are also special deployment tools like capistrano you should take a look at. (if you know this stuff already it may benefit others to read). If you're using FTP you should probably try something different.
If you're working with a site that is still in production, you can afford to make small incremental changes to your local site, then repeat on the live site and down load the new version of the database when your changes are in place. This does mean you double handle the database but can be a safe way of doing things. It keeps both your database closer to each other and minimises risk.
You can also export views backup to your server in either your code or importing them into your live site. There is a hack to get around deploying cck changes here: http://www.tinpixel.com/node/53 it works OK but cannot truly manage changes like rollbacks. (Respect to the guy who wrote that)
You can also use hook_updateN to capture changes and then run update.php to apply them. I worked on a d5 site with dozens of developers and this was the only way to keep things moving forward. This may be a good option if your site is live or if you need all database schema changes captured in a version control system (so you can roll back).
Also: Take a look at drush and drush make. These tools can be of great benefit. I can't remember how much support is for d5.
One final method of dealing with this is not to use cck or views (and use hook updates). But this is really only suitable for enterprise sites where you have big developer resources. This may seem like a strange suggestion but it can negate this whole problem completely.
Sorry I could not give you a clear answer. This is because one does not exist yet. You'll end up finding your own rhythm once you get into. Just keep backups of your database if you can roll back to them easy enough.
I work for an agency that has been responsible for maintaining a client’s .net 3.5 website for a number of years along with another agency. Work is farmed out by the client to both agencies on a pretty much ad-hoc basis.
The site is quite old and has a structure and deployment process to match. The site is setup that developers have local copies of the sites. There is a staging environment, where client feedback and approval happens, followed by the live environment. There are a number of scenarios where work from one agency will be on the staging environment awaiting approval, and changes from the other agency need to go through staging, approval and deployed to live without the original changes being affected. Most of the time we get away with it but it’s far from ideal as not all conflicts can be resolved.
Up until recently we had still been on Sourcesafe but have moved over to Subversion and are running into many more scenarios where work is overwritten. This obviously isn’t a fault with subversion, rather that the locking of projects and files in Sourcesafe served as a good indicator to developers from both agencies that someone was working on that project or file. The process previously was that you checked out a file from sourcesafe and kept it checked out until changes went live (acknowledge that this is a rubbish process hence the desire to move away from sourcesafe and such a model)
The trouble is that even though we know that the way we do it now is bad, I’m at a bit of a loss as to how to restructure the overall site and deployment process to make it “better”. Some ideas we’ve pondered are:
Separate dev, test and live branches in subversion so we need to commit and build the appropriate branch before deploying (not really sure how to make that work)
Single repository for both agencies but a separate staging environment for each. Staging environment could then reflect the changes assigned to each agency
A separate instance of the staging site for each branch
Any suggestions of next steps or examples of similar situations and solutions from the SO community would be greatly appreciated!
Thanks
Joel
I would recomend:
Use git, its really very good for working out how to merge changes.
Have seperate staging enviroments for each company, then, once changes are approved, merge (carfully) into a final staging environmet that only exists to help sort our merging issues there, then push to live.
Also make sure both agencies know who's working on what and try to wait for the other agency to finish working on part X of the app until the other has finished, in the end this is the best solution, a little bit of comunication.