Dariusz on Software Quality

30/01/2011

GIT: Automatic source code version information

Filed under: en — Tags: , — dariusz.cieslak @

Supporting releases: It’s very important to know exact version used by customer. In order to reproduce the error you have to switch to codebase used for reported release and analyse the problem.

If you have fixed release cycles it’s pretty easy to embed version number on “About” page and get that information with bug report from customer. wait, but what about “continuos delivery” practices (there may be many different software versions pulled between official releases)? And what about human mistakes (one can forget to release software without version updated)?

The answer is: automation. You have to embed branch/commit ID somewhere in application (to be visible for end user). Then you can point exact software version that was installed on this particular machine.

You can find below how we retrieve branch name / commit ID with GIT/C++ environment (our Makefile fragment):

git branch -v | sed 's/no branch/no_branch/' \
    | awk '/^\*/ { print "#define APP_VERSION \"" $$2 " " $$3 "\"" }' \
    > headers/version.h

version.h file is regenerated automatically on every build (and is not stored under GIT), so it will be always filled properly. Based on this automatically generated files you can show version information in UI or insert it into logs (it depends on your application type).

26/01/2011

GIT: importing remote branches

Filed under: en — Tags: , — dariusz.cieslak @

GIT is a fast version control system that handles branching very efficiently and allow for most operations to be done offline (is a distributed VCS). Of course sometimes you have to exchange code with external GIT repos (maybe central storage). Being distributed forces some design decisions: local/remote branches distrinction were introduced.

Remote branch in GIT is a head that tracks branch stored on server. You shouldn’t update (commit) directly that branch. You can update local branches instead then use “push” to publish changes from local branch to remote. Remote branch can be used to answer the following questions:

  • is my local branch up to date regarding to server state?
  • what changes (diff/log) were added to my local branch and aren’t submitted (push) yet?

In order to use properly remote branches you have to create maching local branch for every remote branch. Boring and error-prone task. Let’s automate it:!

git branch -a | awk \
    '/RELEASE/ { sub("remotes/origin/", "", $1); \
    print "git branch --track " $1 " origin/" $1 }' | sh

Above command imports all branches that contain string “RELEASE” (I assume we may be interested in checking release status).

11/11/2010

“git cherry-pick” for Perforce

Filed under: en — Tags: , , — dariusz.cieslak @

Cherry-picking is a technique of porting only selected commits from one branch to another. It’s directly supported in GIT by special command:

git cherry-pick <SHA-COMMIT-ID>

Also SVN has simple merge mode that supports selecting of single commit:

svn merge -c <REV-NO> <URL>

What about Perforce? After checking Perforce documentation for merging I hit the following syntax for selecting subset of changelists to merge:

(more…)

08/11/2010

Software Releases Using GIT

Filed under: en — Tags: , , — dariusz.cieslak @

Releasing Software is not just packing latest version to tarball and send to SFTP server. It requires preparation and some planning to be done properly. I’ll describe release procedure I applied on one of my latest projects. Supporting version control system is GIT.

The aims for releasing procedure designed:

  • allow for testing window before release date
  • have the possibility for examine released version to test for reported bugs
  • possibility to manage existing releases (hot-fixing critical bugs)

(more…)

Git: “pull –rebase” by default

Filed under: en — Tags: , — dariusz.cieslak @

GIT is a distributed version control system that allows to share codebase between developers. Born in Linux kernel world proved to be very useful for any programming task. “Distributed” means you can commit locally (during flight), syncing commits to some external repository is done in separate step (at the airport, waiting for luggage).

During watching my commit list using gitk I noticed many developers are accidentially merging their changes without so called “fast forward” (additional commit is created and the history is not linear). Why? The cause is that they are pulling changes from server AFTER local commit. A example commit tree taken from this worth-reading article:

(more…)

« Newer PostsOlder Posts »

Powered by WordPress