Wordpress development process

I don't really know Wordpress, but the process you describe is definitely possible (I've implemented similar solutions on Drupal and Adobe Experience Manager, for instance).

However...

It's hard.

In a CMS project, a change/new feature can include:

• a code change (PHP, CSS, JavaScript)
• a database structure change (e.g. a new table)
• a database content change (e.g. a copy fix, or default/test content)
• a configuration change

Working out which version should get what is really hard. You want a developer to commit a change, and have that change replicated on QA with test content - but once QA sign it off, you probably don't want to promote that test content to production. And config changes should probably flow between systems but with different values for each environment.

For managing the database changes, I've found a plug-in that monitors database changes; no idea how scriptable that is.
See WP Activity Log.

What I've done in the past in similar situations is write a script that creates the database definition for each change - so a developer can run that script, and commit it as part of their code change. It requires a lot of discipline, though - you can only modify the database structure by using the scripts.

The correct answer is yes you can do this. I know WordPress, Bit-bucket, GIT, SVN, Linux, Ubuntu exceptionally well. I have built a system very similar to what you describe and use it daily.

The problem stated is the CMS can get tricky. That is true, but you need to use the correct tools for the correct upgrades. So, WordPress ALREADY has versioning and revisions built into it. The DATABASE doesn't need to be involved at all

First off. The database doesn't need to be updated unless you are updating plugins. But for strict development no DB pushes are necessary. So have your developers check files in and out of Bit-bucket. When the lead developer approves the changes have him migrate / push to the MASTER BRANCH in your REPO. Inside of bit-bucket there is a tool called GIT HOOKS. You can trigger a php file on the server every time there is a push to the production branch. What the PHP file does is simply trigger the linux command GIT PULL which will update all the code on the server with what in on your PRODUCTION BRANCH. GIT PULL will also remove any files if files were removed etc. On the server you will have a "checked out" copy of the GIT repo and on linux the credentials after the first clone will be stored. Simply have your PHP file trigger a BASH script that does a GIT PULL. Done.

No matter how many developers you have there will always need to be a set of eyes that reviews the code changes and merges those into production. I.e. that is where the Lead Developer comes into play.

FYI. The only directories in your wordpress instance that needs to be in bitbucket is the THEME DIRECTORY and the PLUGINS directory. You DO NOT need to sync the entire WP install which is pretty large.

In the case that you would be building custom Plugins, again, it is just code that is stored in the plugins directory. If your custom plugins are built correctly and require the use of Databases then when they are activated they will immediately build the WP DB's that are needed. Likewise, correctly built plugin will also drop its own custom table when uninstalled.

You will need to sync the 2 below directories.

Plugins folder resides in: wp-content/plugins/

Themes Folder is wp-content/themes/SELECTED_THEME

Any additional questions just ask and I am here.

From my experience it is always better to allow each developer to have their own Branch and to setup the the Dev server a dedicated master branch for quality control. you can check out some documentation on how to set this up https://plixxer.com/docs/server-management/website-quality-control/

basically you want to have a live server and dev server. The live server should only ever pull from the REPO and and the Dev and coders can pull or Push from the repo. My team treats the dev server as a quality checking station. If the current live code is not up to our standards the entire dev is rolled back to what is live on the master branch. When code in the master succeeds our standards we pull from the master branch onto the live server. Each developer should have their own branch for testing on their local server. Let me know if you need some help on setting up a local environment with GIT.