Managing Code Development 1

An interesting problem arose today. After spending time evaluating a solution for a client, I developed and modified a branch of a base code called “beautify_variations”. The master branch is of course “master” and it is not only the master but the code base. If I were to take another client asking for another feature for a custom specials widget then I can develop a branch called “custom_specials_widget”.

The Code Base

The base code “master” branch is very important. In order to troubleshoot for clients I need to have a code base which is default, which is easy to configure, bare minimum, and capable of reproducing all standard features without problems of conflicts with other pieces of code and so on so forth. My master branch does all of that. And to start with a new client I only issue:

[code]git branch[/code]

Which will list all my branches and the branch that I am currently in. And then:

[code]git checkout master[/code]

This will set me back to 0 default to an environment that I can trust and start developing with more confidence than before knowing that everything is saved automatically and I can pickup work anytime from anywhere again.

Being able to do this switching with one command line is just what a developer needed the most. One with several requests from clients of course.

The Construction of Solutions

If a client request a type of customization that is on my archives but it requires some extra modifications there should be a way that I can take the code base, apply the customizations from the archive and then merge all of that with my new customizations. All the more, one would like to set this new code solution as a client custom branch. Can I do this? Yes! We will see this in more detail in the future, I will add in this post my experiential findings.

Deployment Scenarios: Patches

Deployment usually conveys the idea of a far repository or server. This is important since we cannot know all the details of the remote server to where we are deploying our improvements to the code. A deliverable therefore needs to be precise as to what part of the code is changing and we would like to streamline the process through the use of patches. A patch, in this scenario, becomes a diff between a common code base and my improvements. How to automatically run it or have it run by someone else is an important part of delivering patches. We must use patches and “unpatches” in case we negatively impact the code base and can quickly undo our patching.

Deployment Scenarios: Upgrades

From time to time the code base is upgraded to a new version. This creates earth movements that threaten my code base’s stability. They can or cannot introduce new bugs, they can fire up old bugs and can create a lot of confusion with new features conflicting with my old changes. The whole archive of customizations needs to be well documented and specify for which version of the code base the custom code was developed. The new code is public ideally, so one can do merges and update with time since all the information is available to us.

The use of submodules can help this process of upgrading code bases, however, when the customizations are made to the code base we require a quick and systematic way of doing this upgrades. Any takers?

Leave a Reply

Your email address will not be published. Required fields are marked *