Hg WorkFlow

Introduction

Nowadays, even the experienced developers find it difficult when a project is handled by more than one developers in terms of branching. Developers just randomly commit, push and pull their code hoping that it would work fine. But in many cases a single commit may break down the entire structure of the repository. When a new developer comes into the team the real problems start. Even the developer who was doing the code may not know at what point he can get a stable code, at what part a particular feature was implemented etc. This led to the rise of various work flows. 

The workflow which I am explaining below is for developers who are using mercurial version control.

HgFlow

In Hg flow there are only 5 branches as;

• Develop
• Default
• Feature
• Release
• Hotfix

First of all we have to initialise our repository with this work flow. Before initializing the repository will look like as in figure below in sourcetree(client app for version control).

 There is only a single branch which is default as you can see on the left side.

 There is an extension in source tree for initializing and operating hgflow on the tool bar(see above image). Once we click on hg flow and click OK the repository will get initialized  with hgflow. Two branches get initialized which is the develop branch and default branch.See below images to see the prompt on clicking hgflow and the pop up before initializing hgflow.

 So now your repository has been initialized with hgflow. On left side you can now see two branches namely develop and default. 

Update your code to develop branch. As I said before you should never code in either of these two branches. Split up your work into many number of features. Then start a feature branch. For starting feature branch click on HgFlow in source tree. Now you will see an option to start a new feature as in figure below.

Click on`Start a New Feature`.On clicking they will ask you for the feature name.The prefix feature/ will be added to your feature's name.

Now you can see the feature branch you started in your branches section in source tree as in figure below.The feature branch will be generated from the develop branch.

Now you can start working on this feature as you do now. Once the feature is completed and you feel like giving the build to the internal testers, finish your feature branch by clicking on the HgFlow.Just check the popup that appears to see finish feature option. Once you finish the feature, the feature branch will get disappeared in the branches section of source tree. The feature branch will automatically merged to the develop branch.Now, in the same way as you started a feature branch, start a release branch. The release branch will be started from the develop branch and therefore now will have all code from your first feature.The internal testing build should be given from this branch. All issues raised by the internal testers on that completed feature should be fixed in this branch.

Once the build is stable you can finish your release branch in the same way as you finished your feature branch. Finishing your release means that the code now you have in that branch is a stable one. Finishing your release branch will merge the code in that branch to both default branch and develop branch.

We can run a release and a new feature at the same time. Only thing is you will have to resolve any merge conflicts that arise when you finish your second feature.The main point or the main advantage is that the default branch will be always having the stable code which means the client will get build from this default branch.

Once the client starts raising some bugs based on the build given to them, you will have to start a new hotfix branch the same way as above.It will be originated from the default bramch. Fix the issue as early as possible and finish the hotfix. Finishing it will merge the code to both default and develop.

The flow will continue like this.

But if you are using client app like tortoise-Hg then you will have to everything manually using terminal commands. Here, for initialising repository with hg flow download the hg-flow.py from hgflow.py and place it some where in your system. Then edit your .hgrc file in the repository and add the following content.

[extensions]
hgflow = /PATH/TO/hgflow.py

Then change directory in terminal to your repository folder and initialize your repository using terminal command

hg flow init

When  asked for branch names, use default names

Branch name for production release : [default] 
Branch name for "next release" development : [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Version tag prefix? [] 

This following command will create a new feature branch . Hg will switch this branch automatically.

hg flow feature start <name>

Finish a feature

hg flow feature finish <name>

This command will close the feature branch. The content in this branch will merge to the develop branch.

Switch between feature branch

hg flow feature switch <name>

This command will switch the branch between feature branches.

Close feature

hg flow feature close <name>

Close this branch and drop the code.
Similarly for release branch and hotfix. For more commands , refer HgFlowManual

Conclusion

The diagram below says it all.

 From this flow a new developer coming into the project can easily understand at what point he can get a stable build(default branch) , at what point a particular feature was implemented etc. Code review can be done on the development branch. Continuous integration servers can distinguish builds based on the branch from which build got triggered and can deploy it to corresponding environments.

In short, just follow HgFlow , this will certainly make your life easier.

Continuous Integration

Introduction

Everyone is speaking about continuous integration. There is a buzz going around on what is continuous integration, what are it's advantages, which are the tools available,  which one to use etc. Well, we will start with answering the question "What is continuous integration?" 

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. It is simply a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. 

So what advantages does it bring?

Solve problems quickly from Thoughtworks

Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.

Continuous Integration is cheap. Not continuously integrating is costly. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

Continuous Integration brings multiple benefits to your organization:

• Say goodbye to long and tense integrations
• Increase visibility which enables greater communication
• Catch issues fast and nip them in the bud
• Spend less time debugging and more time adding features
• Proceed in the confidence you’re building on a solid foundation
• Stop waiting to find out if your code’s going to work
• Reduce integration problems allowing you to deliver software more rapidly

Best practices of CI include:

• Committing code frequently.
• Categorizing developer tests.
• Using a dedicated integration build machine.
• Using continuous feedback mechanisms.
• Staging builds.
• Maintain a single source repository
• Automate the build
• Make your build self-testing
• Every commit should build on an integration machine
• Keep the build fastTest in a clone of the production environment
• Make it easy for anyone to get the latest executable
• Everyone can see what’s happeningAutomate deployment

How to do it?

• Check out code
• Commit changes frequently
• The CI server will trigger builds for every single change
• Then it runs unit and integration tests.
• Then it publishes all artifacts
• A build label can be added to the build output
• Mail will be sent out to the developers based on the result of the build.
• Developers should fix all issues as early as possible.
• Co-developers should make sure that they don't push code over a broken build
• They should also never pull the code from the repository which was failed in the CI server.
• Now, just go with the flow.

Tools used for CI

 Now the question is about the tools used for CI. Wikipedia provides a very big list of continuous integration tools available. But from my perspective , I feel that TeamCity is the best one. So the question, Why TeamCity?

Pre-Tested Commit: No broken code in your version control. Ever.

 The above image itself is self-explanatory. Unlike the standard scenario (edit, commit, verify), TeamCity's Pre-tested Commit feature allows you to remotely verify your changes BEFORE committing them to the VCS. 

 If your changes pass, TeamCity (in cooperation with your IDE) AUTOMATICALLY commits them to Version Control. If they fail, your code won't be submitted to the VCS and you'll receive a notification (by email, IM, your Windows System Tray, or in your IDE), allowing you to fix the failed code immediately. And unlike the standard scenario, you'll always know WHO broke the code. Most importantly, your team never stops working and there is never broken code in your Version Control.

And that's not the only big difference in TeamCity.

Other TeamCity features include:

• A Distributed build grid architecture — Your computer never slows down to run builds. You can simultaneously run builds for different Configurations (app servers, platforms, databases, frameworks, etc) — making Continuous Integration more continuous
• Remote Run — The same thing as Pre-tested Commit, on the Distributed Build Grid, without the Commit
• Server-side code analysis and code coverage — seen directly in your IDE (only for IntelliJ IDEA-based IDEs users for now)
• Tight IDE integration — allowing such things as jumping directly from an error report to the exact line in your IDE where the test failed — as well as many other features. 
• Rich web interface — with detailed and well-organized information.

NB: Taken from Jetbrains

In Jenkins…

• NO SECURITY by default? Why? TC secures out of the box. Common man. 
• No PreTested Commit – a TC standard that’s integrated with Intellij/Eclipse – Jenkins no intention to add 
• Defaults to port 8080 … way too common a port for DEV’s. Will conflict with all Java devs 
• Startup logs are to .err.log? Why? 
• Lack of timestamps in 2 of 3 logs
  Plugin install still triggers server restart, even if no plugins were updated/installed 

Choose TeamCity if …

Does many of the following apply to your case? If yes, then you probably need TeamCity:

• you are middle to large company;
• you have enough money to spend on CI. Not only now, but in the future as well;
• you need guarantees, that you CI works perfectly any time;
• you need the newest features;
• you expect most of the options, maximum flexibility and usability;
• you builds are distributed with some custom setup;

Advantages of TeamCity

• distributed build. Hudson and TeamCity do support distribution. TeamCity has some more options. So, just a tiny here;
• professional support. There is a dedicated firm (JetBrains) with skilled professionals. Hence, you can expect consistent code, good documentation etc…

And if you buy the licenses, you can request new features and plugins just for your special case.

• build from multiple VCS roots. One build, many repo locations;
• many advanced options, largest feature list. Example: it is not important for you if you don’t need Skype notification. But if you do, that may spare you weeks or more if this feature just happens to be already there. If not, Jetbrains will make it happen (only if you are a customer);
• large enterprise needs permanent partner. You cant expect the open source community to be your permanent partner. Yes, you can hire some contractors near to those projects, but it might be not enough if you are a big company. 

Conclusion

By adopting both Continuous Integration , you not only reduce risks and catch bugs quickly, but also move rapidly to working software.

With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fueling real change in your organization, and turning your release process into a business advantage.