Automated Database Update Or Rollback

One of the important step during release is doing database update and rollback in case something goes wrong, usually people perform this operation manually. In this blog I’ll talk about how we can automate this process by following some convention.

Here I’m taking mysql database as an example we can have same conventions for other databases also

Convention to manage rollback/updates of a release

  • Each project codebase at it’s root will have a folder database_scripts
  • The database_scripts folder will contain folder for each release i.e Release1_1, Release2_0…
  • The database scripts release folder will in turn contains two folders update & rollback which will contain updates & rollbacks scripts for a release.

Automating the rollback/update

  • The update folder will have a source input file FileSequencer.txt. This file will point to all the update scripts in correct order that needs to be executed for the release
  • In the similar manner rollback folder will have a source input file FileSequencer.txt. This file will point to all the rollback scripts in correct order that needs to be executed for the release
  • At last we will have a utility shell script, this script will take db details and execute all the scripts referred in FileSequencer.txt using mysql command

Release Strategy for Java Web based projects

In this post I’ll be discussing about the 2 strategies that  we can follow for releasing a Java based web project.

A project can be primarily released in two ways
    Incremental Release
    Full Release

Incremental Release is done in big projects which has multiple modules & usually few modules gets updated between two releases. It makes sense to include only updated modules in release archive and during deployment only update those modules in application server.

Full release is usually done in small projects where the release archive contains all the components and then this release archive can be deployed to the application server as a whole

Both incremental & full release strategy has their pros & cons, where full release strategy scores in simple release archive generation & deployment incremental release has upper hand in space usage by only having modified components in it, although it brings overhead when doing rollback.

Release Steps in Incremental Release Strategy: If you are following incremental strategy in general you need to perform following steps

1.) Checkout the latest code for the release
2.) Generate the list of components which needs to be deloyed for the release
3.) Generate the release archive based on the list of components
4.) Stop the server(If hot deployment of components is not available)
5.) Take the backup of existing application on application server as we may need to do rollback in case of any issues
6.) Replace the components in application server with the components in the release archive
7.) Start the server(If hot deployment of components is not available)

Release steps in Full Release Strategy: As explained earlier Full release strategy is fairly simple, steps involved are:
1.) Checkout the latest code for the release
3.) Generate the release archive for whole application
4.) Stop the server(If hot deployment of components is not available)
6.) Deploy the release archive to the application server
7.) Start the server(If hot deployment of components is not available)

Git : How to fix issues in a merged branch

Sometime back we faced a peculiar problem in our project where we have to fix some issue introduced due to a merged branch. To explain this problem first I’ve to explain the way we manage branches. As we entered in the maintenance mode of project there was a dire need of fixing issues and working on change requests in isolation. Whenever we need to fix an issue we cut a issue-branch out of main branch fix that issue in isolation and after verifying and making sure the issue is fixed we merge that issue-branch back in main branch. The issue we faced with the approach is that after merging an issue branch with the main branch sometimes we came across some regression bugs due to the issue branch. There were two possible solutions to overcome the problem.

First solution is to fix the issue in issue branch and merge the issue branch again with master. This solution can work but the problem with this approach is that till the time you haven’t fixed the issue introduced due to issue branch and merged it back with master branch you can not create a new issue-branch and much bigger problem is you can’t release.

The second solution is if we can somehow revert the merge of issue branch with main branch and then fix the issue in issue-branch, after that merging the fixed issue branch with the main branch. This approach seems to be straight forward and more logical. Git comes up with a cool command git-revert which can revert existing commits and even revert merge of another branch. I’ll talk about the solution in the next blog 😉

My experience with Git

Few days ago I came to know about git, so to give it a try I created an account on github. To those who doesn’t know much about it GIT is a fast version control system :). Since I’m using windows I’ve to download a git client, so the first google result that came on typing “git window” was “msysgit”. Msysgit comes with 2 options “gitbash” a command line utility and git ui so you can use any of them, for initial learning perspective I preferred GitBash.

I’ll not explain the concepts of git as there is lot of information available on the net
http://en.wikipedia.org/wiki/Git
http://git-scm.com/

So first I’ve to create a remote repository. GitHub provides online project hosting using git, they have different plans as according to your needs. I’ve created a free account so I can create public repostiories, which means anybody can checkout the code and you can allow people to modify the code. If you want to create private repository then you have to create a paid account, they have multiple plans as per your need https://github.com/plans. So my user at github is sandy724.

In next blog I will discuss how I’ve used GitBash for synching up the code with remote repository

Equals implementation for Lazy loaded objects in Hibernate

Most of you already know about the standard way to implement equals and hashCode for a class. As an example lets consider a User class


public class User {
private Long id;
private String name;
private String address;
}

If we consider Id as unique identifier for logical equality of users then the equals and hashCode method can be written over “id”, as given below


@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((id == null) ? 0 : id.hashCode());
return result;
}


@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
User other = (User) obj;
if (id == null) {
if (other.id != null)
return false;
} else if (!id.equals(other.id))
return false;
return true;
}

Now lets assume User is an entity thats managed by hibernate and is lazily loaded. So actually you will be interacting with the proxy(HibernateProxy) of User and not the actual User class.

Now in this the equals implementation of User class will fail. If we check for equality of normal instance of User class with the proxy instance of User the equals method will return false. The reason for failure is the class check i.e


if (getClass() != obj.getClass())
return false;

Since the class of Proxy user object is not User but a HibernateProxy class.

To overcome this problem hibernate comes with a utility class HibernateProxyHelper which is used to get the actual class if the object passed to it is of type HibernateProzy. The above piece of code can be replaced with


if (  HibernateProxyHelper.getClassWithoutInitializingProxy(obj) != getClass() ) {
return false;
}

Another problem with the implementation of equals in case of proxy objects is we cannot directly access the fields i.e


if (!id.equals(other.id))
return false;

as proxy objects can access only the methods of the underlying object so instead of directly accessing the field we have to use the getter method


if (!id.equals(other.getId()))
return false;

So the updated equals implemention that should work perfectly fine in case of proxy objects also will be as given below


public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (  HibernateProxyHelper.getClassWithoutInitializingProxy(obj) != getClass() ) {
return false;
}
User other = (User) obj;
if (id == null) {
if (other.getId() != null)
return false;
} else if (!id.equals(other.getId()))
return false;
return true;
}