what to choose for CI? SVN GIT...?

31 views
Skip to first unread message

Shimon Doodkin

unread,
Dec 16, 2012, 5:32:12 PM12/16/12
to iltec...@googlegroups.com
i want some order in our working environment.
i want some server for CI mainly for automated testing and i want a central repository - for source-s won't get lost on developer's computers and would be accessible from every computer.

the situation is like this:
we have about 10 developers. 2 of  them once develop a website and store it in a central repository.
once in a while a developer will: take the source from a central repository ,modify it,deploy it to client's server,  and put the source back to central repository. 
we have about 100 websites to maintain in a central repository.

the problem i see with git is that the server will have to merge pull requests regularly.

what to choose ? SVN GIT...anything else?/how to integrate it, i guess with Jenkins and msbuild
any experience?

*the development is in in C# and vba - dot net nuke




Emanuel Ilyayev

unread,
Dec 16, 2012, 10:36:39 PM12/16/12
to iltec...@googlegroups.com
You don't have to manage pull requests regularly. Git is all about decentralized management of your code. If you have one person that manages these "pull requests" then you guys are missing the point of managing your code with Git... I would suggest to go ahead and open a free account at BitBucket to get some idea/experience with Git. You would also probably appreciate "Tortoise Git" that wraps git commands with a user friendly GUI...

In general, the rule in team work is that before pushing your code to the server, you have to pull the changes and merge your changes with the changes pushed before you by other developers. Thus every team member is responsible for merging his code and there are no "minions" that required to do this task for you. When you are working on entirely new feature then you create your own branch and when you finish the feature you merge this branch with the master.

I would say that before you jump any farther to Jenkins, msbuild or any additional "must to have" staff (e.g. unit tests, regression tests, automated staging and development environments, automated deployments, backups, rollback-ability etc.) make sure that all of your team members know how to work with git first. This would be a major shift for you guys, so take it easy, step by step...


HTH
--
Emanuel

Lior Friedman

unread,
Dec 18, 2012, 1:29:01 PM12/18/12
to iltec...@googlegroups.com

Hi Shimon,

 

While I don’t have enough working experience with GIT (I’ve been using SVN in most of my recent workplaces) the process you describe sounds more fitting to a centralized source control system (such as SVN). A  distributed source control like GIT means a different way to do things.

In any case both tools are used widely enough to be supported by almost all CI servers out there.

 

Regarding your CI,

I think you should check out TeamCity before you go down the Jenkins road. Jenkins is more fitted to the Java world and less to the .Net.

Also, I urge you to try avoiding MSBuild (or any XML based build technology). A visual based build technology (FinalBuilder Visual build,…) is much more cost effective in the medium-long run. While at the start (where you build is relatively simple) the difference will not seem to justify the costs involved down the road (and not too far) the ROI will be positive.

 

And last, I think that setting up a CI server and starting your automation road is actually more crucial than the exact source control tool you will choose (given that you will use one).

 

Hope this helps

Lior Friedman

Reply all
Reply to author
Forward
0 new messages