Version workflow for several similar (but not identical) deployments

Question

I currently work in a small non-technical organization and have been given the role of coding the organizations website. While I enjoyed this task and learned a lot from the web developer, I ran into several problems that I hope that someone can help me or at least point me in the right direction.

A bit of background:

The site I work on has subdomains on which each one has its own separate WordPress installation, as it was the lightest backend control panel for the type of user who will be responsible for updating the content (etc.).

Within the organization, I work under the direction of the Marketing Manager (MM) and I am in accordance with his style and wire management guidelines.

While we have been working with one subdomain since the beginning of the year, the project was relatively simple and straightforward. However, recently the workflow has become a bit more complicated, as our original subdomain has been copied to other subdomains. Each of the new subdomains receives minor changes in their style sheets (for example, different images for the background, slightly different colors here and there, etc.).

Problem:

At the moment, managing all of these subdomains is “tolerant,” but the straw that slows down the camel at the moment was a small twist that MM required now that the CEO saw the final product. The problem I am facing with reversals in style sheets is that the CEO will declare that he likes the change of “X” and then like MM and I keep changing the site (now “Z”), there will be another the state of the week, he wants us to change “X” to “W”, but save most of the changes made to “Y”.

I am looking for something that allows:

• tracking file changes
• returning changes made (or returning to 'a' from 'e' but including changes to 'b' and 'c')
• easily download the necessary files to their respective WP theme installation

Is something close to solve these problems? If so, then what?

Thanks for any help!

PS - I am studying Git at the moment, and it seems that it is very convenient. However, have not yet learned about the return changes. Perhaps for my last moment I'm going to create a shell script to automatically upload files to my folders. Does git do this too?

---

Addition (alexbbrown)

I had a similar problem: I launched a custom version of mediawiki where I installed various extensions in the versioned kernel (with svn). Each of the extensions required a section in the confit file, but the confit file also needed a local configuration for each of several deployments. I could implement it with include, but they will not be versioned; and reinstalling branches each time is a chorus. +50 experience points for a good answer in git.

Answer 1

Git will let you do what you need.

I would use one repository containing each subdomain as a branch, since in my experience this will allow you to move changes between subdomains in the easiest way.

I am going to assume a structure in which you have a core branch, and several subdomainX branches, each of which has its own local changes to support. I also assume that you have a develop branch where you make major changes.

There are several key actions you need to perform:

You have made development changes that should go to all subdomains

Pull changes from development to the kernel

 git checkout core git merge develop 

Apply changes to subdomain branches. For each subdomain, do

 git checkout subdomainX git rebase core 

or if you prefer mergers over discounts (I find this case too confusing, but others may not agree)

 git checkout subdomainX git merge core 

If you have many branches of a subdomain, I would do this script. This will result in the rearrangement of all local branches containing the "subdomain" in their name on core .

 for i in $( git branch | cut -b 3- | grep subdomain ) ; do git checkout $i git rebase core end 

You have made changes to the subdomain that you want to pull into all other subdomains

First you need the SHA of the change you want to apply (and check it if you haven't done so already).

Then you pull only this change to the development branch, and then to core

 git checkout develop git cherry-pick THE_SHA_OF_YOUR_CHANGE git checkout core git merge develop 

Then you just run the script above to push the change to all branches of the subdomain.

You have git some changes that should be rolled back everywhere

 git checkout develop git revert THE_BAD_SHA git checkout core git merge develop 

Then run the script.

You want to compare two subdomains.

If two branches are called subdomainA and subdomainB , you can do

 git diff subdomainA subdomainB 

You want to know what changes are happening in subdomainA, but not core - that is, local changes.

Changes to the files can be obtained:

 git diff subdomainA core 

Actual change set list

 git log core..subdomainA 

Distribution processing

There are two ways to deal with this:

• Create a small script to copy files for each branch (I would use rsync to avoid copying existing files, etc.). The advantage of this is that it is fast and does not require git on the server on which you are deploying.
• Make each subdomain file a copy of the git repository. Your script will then ssh for each window and pull / merge the files. The advantage of this is that you can make changes to live servers and easily transfer them back to your repository. The disadvantages include the fact that you need to create a bare repository as a source for all repositories, and this will take up more space. (However, IMO advantages in this case outweigh the disadvantages, and this is the approach I would use).

Answer 2

Michael's answer is good, but there is another point of view that I think should be mentioned: Branch by Abstraction (BBA) instead of the traditional "Branch by Source Control". I think you should reorganize the source code so that the common code should be made as explicitly shared code instead of merging / rebases.

It might be worth adding some build scripts that will reorder the code and run some tests to verify the correctness.

Answer 3

Good idea to implement git! This is definitely an indispensable development tool. As you already mentioned, git will definitely solve your problem with changing the tracking file, and also be able to solve other problems, there is another learning curve. There are many great resources on git, but if you want to better understand what git is (and what it is not) and how it works, I would recommend reading Git from the bottom up .

Reverting changes can be done very easily with git. First, you probably need to look at your transaction history to find the one you want to return. This can be done simply with the git log command (make sure you are in the directory tracked by git). Here is much more information about here . After you know the commit you want to return to, all you have to do is use the hash associated with that particular commit and run git reset --hard 6e3e02050a , where 6e3e02050a is your commit hash code. For more information, including some interesting things you can do about it, here . This will immediately return all your monitored files to this particular commit (you can also undo individual files).

Believe it or not, git can also help you push your code to your servers automatically whenever you want. It is a bit more advanced and uses post-receive hook . This facilitates deployment from development to production. Since I recalled that this is more advanced, so I will not delve into the features of this here, but there is a great tutorial that includes exactly what you want on wp.tutsplus.com (step 4).

Now all these things are quite simple for one installation, but it gets a little complicated when you have many sites, all of which are connected with the same development process. Again, git has some options.

I assume that at this point you can learn a little about branching if there are not many resources . Branches allow you to shoot back in search or even completely separate projects from your main "leading" branch. It seems like this is exactly what you want, with all of your settings based on the same main code. Another advantage of branching is that you can constantly update your branches with any changes in the wizard, as well as merge them back if you want. Another option is cloning. This is different in the fact that you are actually copying the entire repository, and not just branch out with what you have. Read more about it here .

It may take some time to figure out how best to configure everything, but I can guarantee that as soon as you have some kind of process, you will be very pleased with the options and peace of mind that git can give you.