A year with Git
It’s almost a year ago, I’ve posted the article How to start using Git in SVN-based organization. It has been viewed more than 3,000 times on my blog and more than 9,000 times on re-post by DZONE.
Time has passed and some of you might be interesting, what happed next? A lot, actually.
I think we followed “Baby steps to..” strategy of Git adoption. Our baby steps to Git, were small, accurate and quite long. But at the end of the day, I’m happy to say - we are pure Git organization now. Moreover, some of our projects are hosted as public and private repositories under the e-conomic organization github account.
Retrospective
So, let’s make a kind of retrospective seeing what things were happening.
- Git-SVN mode. As described in original article, the best way to try Git inside the organization is go to Git-SVN mode. It will allow to use SVN as primary repo, but allow Git features like local branching, cool merging, stashes and other stuff described here.
- People awareness. Started by just few developers the information about the Git had spread along mates in our department. Some were very enthusiastic about that, some not. But anyway, it got attention of our many people including our CTO. The greatest thing is that initiative has not been cancelled, instead we start to think of some kind of plan that might bring us into pure Git world.
- Planning. Our plan including different evaluations, choosing between Git or HG, local or cloud hosting, Centralized or De-centralized mode etc. During this planning sessions we also identified some infrastructure dependencies that blocked switch to Git. We have so called “Language System” the application helping our copyrighters and translators to change the content of app. It’s been creating assuming that SVN used, doing checkouts and commits where. Another thing is that our deployment procedure happened to be SVN dependent. Obviously, it have to be changed to work with Git. But the most priority had “Education” task. Everybody should be able to work with Git.
- Execution. Planning is easy, execution is hard. We did initial education as a series of meetings were the basics are described. Fortunately, almost as teams contained the git-aware person who were initial knowledge keeper. Some important details being moved to company’s Wiki. The problems we start to have local infrastructure setup. Being Windows organization we tried to setup primary repository and server on Windows box. Keeping that short, I just say - don’t do that. It’s not trivial at all, to configure Git server there, setup the accounts and permissions and make it work with TeamCity. We tried different scenarios of Git hosting on IIS, including Bonobo-Git-Server or Git-Dot but all had it’s own limitations, blocking us of full-feature Git usage.
- Trying github. In parallel, one team that was starting out new project and was quite independent tried to host sources in cloud. Github is obvious choice here. I think, that was a great experience and this project is still hosted on github. We tried, so called “organization” mode. It ideally fits small software development shops. Easy start, easy go.
- Linux local server. Failed to run it properly on Windows we had to switch to Linux box. It’s being deployed as virtual box, that is more than enough for Git server. That solved a lot of infrastructural issues, including authentications & permissions as well as CI problems. As I can see the effort to setup it was not so big (if compare to effort spend to make the same on Windows, it would be closer to 0). Setup once, it just start to work.
- Mirroring repositories. The setup of local central server was the first great milestone. Even if all the developers might start to use it instead of SVN, the infrastructural problems that I mentioned in #3 were not yet solved. So, we did a partial decision. The developers are switching to Git repository, but the deployments and language works are still done on SVN repository. So it’s not so frequent operations, it’s possible to synchronize the Git and SVN between each other. It means, all new code started to appear in Git, but once a week (or often) all changes set are being pushed to SVN. This is of course an overhead and required some manual work.. But it was only one way for us.
- Fixing the dependencies. It took some time while everybody got comfortable with Git. Our Wiki has extended with some policies of working with Git. We mainly follow “A successful Git branching model” keeping the feature in local branches, having remote branches for code review etc. After our deployment dependency has been fixed, we were able to push the code to production very fast. I think it’s almost a year passed to now clearly understand benefit of Git not just theoretically, but practically. And that was amazing experience, as so for me.
- Pure git world. After the last dependency has been fixed, we happily entered the “Pure Git Environment” world. The SVN server has been stopped. All developers, DevOps and copyrighters are Git users now.
It took a while…
Yeah, it took awhile but we never had this migration as top priority item in our backlog. The process were long and smooth, allowing us to do our primary job of bringing value to product, but the same time improving the internal infrastructure.
Not being hurry is also good option, sometimes. The whole transition took a lot of efforts of different person along the way. I say thank you, guys - for making this happening.
What’s next?
The things are stabilized now. We are on one solid solution, working very nice. As I said, we have both local and github environments. If I pretend to be a medium and see the future, I would say we go to “pure Github” environment from here. Sure, now this transaction having it’s own dependencies. But let’s see what’s happen during next year.
It’s almost a year ago, I’ve posted the article How to start using Git in SVN-based organization. It has been viewed more than 3,000 times on my blog and more than 9,000 times on re-post by DZONE.
Time has passed and some of you might be interesting, what happed next? A lot, actually.
I think we followed “Baby steps to..” strategy of Git adoption. Our baby steps to Git, were small, accurate and quite long. But at the end of the day, I’m happy to say - we are pure Git organization now. Moreover, some of our projects are hosted as public and private repositories under the e-conomic organization github account.
Retrospective
So, let’s make a kind of retrospective seeing what things were happening.
- Git-SVN mode. As described in original article, the best way to try Git inside the organization is go to Git-SVN mode. It will allow to use SVN as primary repo, but allow Git features like local branching, cool merging, stashes and other stuff described here.
- People awareness. Started by just few developers the information about the Git had spread along mates in our department. Some were very enthusiastic about that, some not. But anyway, it got attention of our many people including our CTO. The greatest thing is that initiative has not been cancelled, instead we start to think of some kind of plan that might bring us into pure Git world.
- Planning. Our plan including different evaluations, choosing between Git or HG, local or cloud hosting, Centralized or De-centralized mode etc. During this planning sessions we also identified some infrastructure dependencies that blocked switch to Git. We have so called “Language System” the application helping our copyrighters and translators to change the content of app. It’s been creating assuming that SVN used, doing checkouts and commits where. Another thing is that our deployment procedure happened to be SVN dependent. Obviously, it have to be changed to work with Git. But the most priority had “Education” task. Everybody should be able to work with Git.
- Execution. Planning is easy, execution is hard. We did initial education as a series of meetings were the basics are described. Fortunately, almost as teams contained the git-aware person who were initial knowledge keeper. Some important details being moved to company’s Wiki. The problems we start to have local infrastructure setup. Being Windows organization we tried to setup primary repository and server on Windows box. Keeping that short, I just say - don’t do that. It’s not trivial at all, to configure Git server there, setup the accounts and permissions and make it work with TeamCity. We tried different scenarios of Git hosting on IIS, including Bonobo-Git-Server or Git-Dot but all had it’s own limitations, blocking us of full-feature Git usage.
- Trying github. In parallel, one team that was starting out new project and was quite independent tried to host sources in cloud. Github is obvious choice here. I think, that was a great experience and this project is still hosted on github. We tried, so called “organization” mode. It ideally fits small software development shops. Easy start, easy go.
- Linux local server. Failed to run it properly on Windows we had to switch to Linux box. It’s being deployed as virtual box, that is more than enough for Git server. That solved a lot of infrastructural issues, including authentications & permissions as well as CI problems. As I can see the effort to setup it was not so big (if compare to effort spend to make the same on Windows, it would be closer to 0). Setup once, it just start to work.
- Mirroring repositories. The setup of local central server was the first great milestone. Even if all the developers might start to use it instead of SVN, the infrastructural problems that I mentioned in #3 were not yet solved. So, we did a partial decision. The developers are switching to Git repository, but the deployments and language works are still done on SVN repository. So it’s not so frequent operations, it’s possible to synchronize the Git and SVN between each other. It means, all new code started to appear in Git, but once a week (or often) all changes set are being pushed to SVN. This is of course an overhead and required some manual work.. But it was only one way for us.
- Fixing the dependencies. It took some time while everybody got comfortable with Git. Our Wiki has extended with some policies of working with Git. We mainly follow “A successful Git branching model” keeping the feature in local branches, having remote branches for code review etc. After our deployment dependency has been fixed, we were able to push the code to production very fast. I think it’s almost a year passed to now clearly understand benefit of Git not just theoretically, but practically. And that was amazing experience, as so for me.
- Pure git world. After the last dependency has been fixed, we happily entered the “Pure Git Environment” world. The SVN server has been stopped. All developers, DevOps and copyrighters are Git users now.
It took a while…
Yeah, it took awhile but we never had this migration as top priority item in our backlog. The process were long and smooth, allowing us to do our primary job of bringing value to product, but the same time improving the internal infrastructure.
Not being hurry is also good option, sometimes. The whole transition took a lot of efforts of different person along the way. I say thank you, guys - for making this happening.
What’s next?
The things are stabilized now. We are on one solid solution, working very nice. As I said, we have both local and github environments. If I pretend to be a medium and see the future, I would say we go to “pure Github” environment from here. Sure, now this transaction having it’s own dependencies. But let’s see what’s happen during next year.