Tag Archives: git

Git & Continuous Integration – Does that work?

11 Mar

In my last blog post I was mentioning 6 arguments why you shouldn’t use Git. While 5 arguments were obviously meant to be sarcastic (who can really think that slow operations like searching the history in SVN can be an advantage) there was doubt about one argument that can be tricky:
Git destroys the idea of continuous integration
In Git you are using branching heavily. Let’s assume everybody’s working on feature branches. Then somebody is renaming a widely used interface or class and checks the code into the mainline. If you don’t integrate your feature branch early this can result in lot’s of conflicts.

Some people favor solutions with an integration branch. People integrate the changes from their feature branch on an integration branch. If the CI-Server has build the software successfully and all tests passed, the changes get automatically pushed to the mainline. That way the mainline stays always deployable and green. I don’t like this solution: The integration branch is basically the mainline. But if a build fails, it is not so important to fix it. Not my understanding of continuous integration.

I stil prefer the SVN statement: “Commit early, commit ofter” what should be translated for DVCS into “Push early, push often”.

Solution 1: Making the mainline the communication point again

Bildschirmfoto 2013-03-07 um 13.23.50

Switch from SVN to Git and work as you have before. Don’t branch, just push your changes to the mainline on your central repository. You still benefit from fast history searching, offline capabilities and much more. Just beware that if you once started with Git, you’ll probably come to use also the awesome branch features, that drags you into a different workflow.

Solution 2: Promiscuous Integration

Bildschirmfoto 2013-03-07 um 13.23.22

Martin Fowler has written a great and much more detailed blog post about Promiscuous Integration. Basically people talk about changes and integrate the changes from feature or personal branch to another. The way changes got also continuously integrated in each others feature branches. When it comes down to pushing changes back to the mainline, you won’t experience lot of merging pain: Changes have already be integrated. Martin is pointing out, that this requires communication between developers and this can go wrong. There is no clear rule which changes you should integrate into your personal feature branch.

My favorite solution: Feature Toggle + Task Branch + Automatic Push!

Bildschirmfoto 2013-03-07 um 13.23.07

With Feature Toggles you design your software that you can turn your feature on when it’s ready. When currently developing the feature is usually off so you can deploy the software immediately. A feature can consists of many tasks. I like the idea to have a branch for each task and push changes to the mainline when your task is done. I assume a Task Branch doesn’t live longer than 2 days. That way you still continuously integrate your changes and work focused on your branch.

You could combine this with a feature Atlassian has build in their Continuous Integration Server Bamboo: Automatic Pushing. If the mainline changes and the build went good, Bamboo is trying to push the changes automatically to your task branch. That way you have always the latest changes in your branch. I guess there is also a plugin for Jenkins available, I just couldn’t find it ;)

In my opinion this is the best of all solutions: The mainline is your communication point, you recognize conflicts very early, merging is not to hard and you have done some things to keep your mainline up-to-date and  your builds green.

Another thing that your CI-Server can help you with is running a build of a potential merge. Before merging for real you can see if your build will succeed or not without pushing your changes already. Jenkins with Gerrit or Bamboo with Stash can be set up for such a workflow.

These are just my thoughts. I would like to know what your experience are with CI and Git. What works for you in your organization?

Tags: , , , , ,

Don’t use Git

21 Feb

no_gitEverybody keeps telling you that Git is better than Subversion. You keep hearing Git has better workflows, offline capabilities and  is faster. But should we really jump on every new technology that is coming around the corner? Your source code is the heart of your software developement and you want to store it with a tool that is working. Here are 6 reasons why you shouldn’t use Git at work.

1 – Git destroys the idea of Continuous Integration

ic_action_collapseGit encourages you to use branches for your development. But when you work for 1 or 2 days on your branch, you’re not continuously integrate your code changes with those from your co-workers. You don’t know if someone changed something important in between that collide with your changes. And if you want to have your build server automatically build your development branch you need to copy the project for each new feature branch.

2 – Developers can be offended

ic_action_sadSVN has this great feature that if you merge a branch to the trunk you lose all commits of the branch. This is great because the developer that has merged the changes is the one that is responsible for the changes. The dev manager can not blame you for a bug. Git keeps all the commit information from a branch when merging to another branch. You can blame the programmer  directly. There is no technical protection for developers anymore.

3 – Git destroys the team experience

ic_action_usersWith SVN merging a change into the trunk is a real team experience. When you see conflicts you have to talk to the two developers that have changed the same code and find a solution. Because of the fact that merging with Git is different you end up with less conflicts and less possibilities to discuss the code changes directly with co-workers.

4 – Developers have too many options

ic_action_playback_schuffleWith Subversion you have a simple workflow for adding your code to the repository:

1. You merge your local changes with the trunk on your machine.
2. You commit the changes.

I will not mention the second workflow (branching) because there are lot’s of discussions not to use branches in SVN. We have one simple workflow that everybody understands!

Git gives you the opportunity of  lot’s of different workflows you can adapt and even combine: Having a Gatekeeper for your main branch, do cherry picking or let everybody pull and push to everybody’s development branch. What a mess!

5 – Git makes people work overtime

ic_action_clock

Subversion requires a server to search the history, create a branch or commit code changes. Git stores the wholes repository on your hard disk (what a waste of disk space). This makes it possible to work without network connection with the same possibilities as if you are in the office and connected to your SVN-server. It’s the perfect argument for your team lead to ask you to work over the weekend from home to hit the deadline of the current project. Don’t use Git and let this happen!

6 – Git is unsocial

ic_action_micoff

Subversion gives you time to socialize when creating a branch, checkout a branch or even switch beween branches. You get some time to chat with co-workers, go to the kitchen and grap a cup of coffee or to write comments on facebook. Git changes the game for the worse: Due to the fact that you working just on your hard disk to do all this tasks in Git, it is faster and you lose the natural social time. It’s good for your dev-manger but bad for knowing what’s going on.

It is pretty clear that we shouldn’t use Git at work. Why should we change at all? SVN is a mature technology that has been around for more than a decade. There is no reason to change to a just 8 year old repository technology. Let’s face it: It’s great for open source but in a corporate environment  offline possibilities and advanced workflows are not so important. We have been working for ages with centralized version control system. Think about the knowledge that is in the SVN community. Some people will be out of jobs if all companies switch to Git.

Don’t let that happen. Don’t use Git!

UPDATE : Did you git it? 

Due to the confusion people have whether this article is meant to be funny or sirous: I love Git and I think it helps teams to do a better job. It solves a lot of problems that we have with SVN. Don’t let our children grew up in a world of Centralized Version Control! Just to be sure you realize that this is just a sarcastic blog post.  Hope you had some fun reading it!

Tags: , , , , , ,

Kick-Ass Code Collaboration

29 Nov

Collaboration on code is important. If we want to do Kick-Ass Software Development we need to get our changes fast, easy and without a big process into the code base and keep the code quality high. I start with 2 problems I’ve seen in software development teams.

Code collaboration problems

The indispensable developer

If you’re a developer that works just in your own codebase without anybody else touching your code, you are in a very unique position. You can commit code changes and apply patches for older versions without notifying anybody else. It’s just you, that have to know the code. But I’ve seen this behavior also when people work together in a team. Especially developers that are working for a long time on the project can have the tendency not wanting to share their code with the rest. These people do it because of two reasons: They are afraid that they got criticized  and they want to save their job and position by making themselves indispensable. This person is a big risk for the company and destroys the team.

The control freak

In other projects you have one or two senior developers. They are so smart and they know the code that well, that every change by someone else needs improvement by them. The other developers in the team (let’s call them shitty developers) have to get their code reviewed by the senior people. If they reject their changes the shitty developers need to change the code again until it looks right in the eyes of the smart developers. Sometimes it takes over a week until a senior person can review the code. They have all tons of other more important stuff to do. You can indicate these “developers” easily when looking in their meeting schedule. Smells like a big unnecessary bottleneck to me.

Kick-Ass code collaboration

With Kick-Ass software development  everybody can change every line of the code. There is no code ownership. When somebody sees a bug, he has to fix it. We share our code to learn from each other. We want to get our changes fast into the master with high code quality to start with the next code changes.

A branch for every task

We use the power of Distributed Version Control Systems like Git and Mercurial at Atlassian. We’ve implemented a simple workflow to avoid having a bottleneck in our development and move fast to the next task. Kick-Ass software developer create a branch for every task. With DVCS this doesn’t cost anything. When the task is done the developer can merge the changes back into the master branch. A task-branch doesn’t life longer than 2 days, so the change set for a branch is small and we can keep the overview. You don’t get lost when looking at the changes. This approach kicks ass because it’s fast, easy and it makes the developer to focus on a small set of work.

Don’t loose the power of CI

We’ve set up our continuous integration server to find all new created branches and apply the built plan automatically to the new branch. So we have an automatic build for each task branch. The developer doesn’t have to care about this. He just gets notified when he broke a test on his task branch. The CI server even deletes the plan automatically when there is no activity on the branch anymore. We even can do a built on a virtual merge: If our developers wants to find out if they will break the built after they merged the code back to the master they can do that without doing the actual merge. This helps us to avoid broken builds on the master branch.

Code quality and sharing with Pull Requests

What about code quality and collective code ownership when everybody can push changes to the master? Oooops, I forgot a detail here. Of course we’re doing code reviews. In Git code reviews are done with Pull Requests. The code author asks some reviewers for their feedback on some recent code changes. The changes are not very big (short living branches) so it doesn’t take long to go through the changes. The task based approach makes it pretty clear what the code change should do. If two reviewers are  ok with the changes the author got notified and merges the code into the master. We normally pick three or four reviewers for a Pull Request just to avoid bottlenecks. Every “approve” counts the same, no matter if it was an expert or a newbie.  The advantage that Git gives you over Subversion or CVS: You don’t have to merge the code before your code review has been approved. Your master stays always clean!

Kick-Ass Developer share code

The most important thing on code collaboration is the sharing part. We can learn from each other and we got to know all parts of the code base. Here are some points to keep in mind on Kick-Ass code collaboration.

  • Kick-Ass Developer are happy to share code with others.
  • Kick-Ass Developer are gentle to each other when commenting on other people changes.
  • Kick-Ass Developer use automation to keep the code quality high and catch problems before they stop the whole team.
  • Kick-Ass Developer trust each other that they won’t harm the code.
  • Kick-Ass Developer can also communicate face to face when an online conversation takes too long
  • Kick-Ass Developer don’t have complicated workflows or processes: branch – code – share – merge

Tools we use:

Tags: , , , , ,

Follow

Get every new post delivered to your Inbox.

Join 26 other followers