integration hell
-
Hello All, We are in the process of reviewing our source control and the way we integrate. Currently we are using SVN but not using it's merging feature etc. All the basic ones like getting latest, commit, put etc. But our team has now increased and quite often two developers end up over writing each others code. Our environment looks like - Test server - where development happens and sit till the functionality is approved Live server - Once functionality is approved and tested, it goes to live (production) server. So my questions are: 1. What do you recommend - svn or GIT or svn is completely fine as long as we use all the features. 2. Should we really be developing in local and then pushing to test server and then production or what do you recommend? 3. Any other tips to automate this process? Thanks
It sounds like you are using your test server as the integration point rather than your source control system. Source control should be your integration point, and when a new test is desired, push from source control to the test server. An automated build process (extract from source control, build, push to test server) might help. It's a fundamental workflow problem.
Software Zen:
delete this; -
Hello All, We are in the process of reviewing our source control and the way we integrate. Currently we are using SVN but not using it's merging feature etc. All the basic ones like getting latest, commit, put etc. But our team has now increased and quite often two developers end up over writing each others code. Our environment looks like - Test server - where development happens and sit till the functionality is approved Live server - Once functionality is approved and tested, it goes to live (production) server. So my questions are: 1. What do you recommend - svn or GIT or svn is completely fine as long as we use all the features. 2. Should we really be developing in local and then pushing to test server and then production or what do you recommend? 3. Any other tips to automate this process? Thanks
A lot of good info in other posts. Here are some other thoughts: Some VCS systems perform conflict resolution best if each developer works on their own private branch and merges to the pre-production branch. Test server has a single pre-production test area that no developer can update! (repeat recommendation) Pre-production should only be updated by refreshing from your pre-productin/"head" branch in source control or pushing from an admin VCS area where zero development occurs. (automate this!) Each developer should have their own sub directory/virtual directory, application server, IP address, entire test server (cloned VM), server on their development box, etc. where they can host their own version of reality without stepping on another developer if they are working on the same files. VCS should handle the merging/integration.
-
It sounds like you are using your test server as the integration point rather than your source control system. Source control should be your integration point, and when a new test is desired, push from source control to the test server. An automated build process (extract from source control, build, push to test server) might help. It's a fundamental workflow problem.
Software Zen:
delete this;I think this is the heart of your issue. It's not the tools but how you are using them. - All changes should be checked in before they go to test. - Test (and Prod) should be always be built from some specific SVN revision. - You probably could use a branch for what's in prod where quick fixes can go and another branch or trunk for the next big release. You'd have to merge prod fixes to the release code. And you might want a dev server to "test" the bigger changes on. Something like that...
-
HobbyProggy wrote:
Never heard of LOCKS
Yes, I very much know about locks but you can only lock it at SVN level not server level. Right? If tom, dick and harry lock few files then I can still push the file to test server and to production after making changes to it? So it doesn't help.
HobbyProggy wrote:
possibility to communicate with each other
That's what we are doing now which takes up lot of time. So need a better solution. Hope you got my point smarty pants? :)
You may be using SVN, but you aren't using it correctly. This isn't a software problem. Here's a super quick, overly simple view of what should be going on: Daily work ================= 1) Check out code 2) Modify Code 3) Developer level / Unit testing 4) Check in code (handle your merge issues) Build ================= 1) Checkout code 2) Tag or version the checked out code 3) Build the code 4) Test the code A) If test successful, push to production B) If test not successful, dump the build. Notice that there is no modification in the build process?
-
Hello All, We are in the process of reviewing our source control and the way we integrate. Currently we are using SVN but not using it's merging feature etc. All the basic ones like getting latest, commit, put etc. But our team has now increased and quite often two developers end up over writing each others code. Our environment looks like - Test server - where development happens and sit till the functionality is approved Live server - Once functionality is approved and tested, it goes to live (production) server. So my questions are: 1. What do you recommend - svn or GIT or svn is completely fine as long as we use all the features. 2. Should we really be developing in local and then pushing to test server and then production or what do you recommend? 3. Any other tips to automate this process? Thanks
There's a lot of good advice in this thread. The only thing I will add is instruct everyone to save a local copy of all changes made. Protecting your work, even when using a revision control system, is a 100-level rule everyone should follow. Trust nothing, servers can fail or be damaged, backups can be unrestorable. Everything will fail, eventually. No one with a lick of sense should get burned twice by losing their work.
-
Hello All, We are in the process of reviewing our source control and the way we integrate. Currently we are using SVN but not using it's merging feature etc. All the basic ones like getting latest, commit, put etc. But our team has now increased and quite often two developers end up over writing each others code. Our environment looks like - Test server - where development happens and sit till the functionality is approved Live server - Once functionality is approved and tested, it goes to live (production) server. So my questions are: 1. What do you recommend - svn or GIT or svn is completely fine as long as we use all the features. 2. Should we really be developing in local and then pushing to test server and then production or what do you recommend? 3. Any other tips to automate this process? Thanks
Are you the leader of this team? If so then first talk with your people and together find a solution. Choose one tool and learn it to heart. Do not skimp over a one page blogsite tutorial. Get a book or a course and take the time to learn it. Backup all your code and start trying the tool, do changes, test it, break it. Do this as a team and learn together. Don't say you don't have time for this. You will lose MUCH more time if your don't learn your tools. Then start using it as a team. When someone has doubts get together and solve it as a team. If someone doesn't understand the tool, get together and teach him/her. Go for it dear leader! :-D
-
Hello All, We are in the process of reviewing our source control and the way we integrate. Currently we are using SVN but not using it's merging feature etc. All the basic ones like getting latest, commit, put etc. But our team has now increased and quite often two developers end up over writing each others code. Our environment looks like - Test server - where development happens and sit till the functionality is approved Live server - Once functionality is approved and tested, it goes to live (production) server. So my questions are: 1. What do you recommend - svn or GIT or svn is completely fine as long as we use all the features. 2. Should we really be developing in local and then pushing to test server and then production or what do you recommend? 3. Any other tips to automate this process? Thanks
cp-andy wrote:
But our team has now increased and quite often two developers end up over writing each others code.
I seems that you have a problem with the partioning of your codebase. Try to identify the hot spots and refacture it (smaller classes, more source files, apply well known design patterns)! Watchout for source code files with many bugfixes and files with too many lines of code. Changing your version control system doesn't help if 2 or more developers make large changes on the same files. Git (or any other version control system with 3-way-merge) can only merge small changes automatically.
-
The simple answer here, I think, is to check in your code when you change it, and not after it has been through the test server process. If it fails testing, you need to fix it, check changes in then submit to test server - so everyone is getting the latest version of the source most of the time, rather than having long delays between getting code and updating. though I'm not sure what you mean by 'test server' in your context - are you pushing code to the test server before checking it back in to SVN?
PooperPig - Coming Soon
Basically, we get latest from the svn and then dev A works on it and pushes to test server directly and not to SVN. Once bugs are sorted and is a stable version, then dev pushes it to SVN and to production server. I am going through all the suggestions now and see what can work for us. Thanks
-
We are a team of almost 100 developers working on the same code. We use git and merge seems to work well in most cases. We do not use a test server because of problems that you describe. Instead we schedule regular 'stability points' that serve as snap shots and used for testing etc. A few days before a stability point, we are asked not to push any major changes while a few team members do some simple testing and fixing before releasing the build for major testing/customers etc. Anything major is then fixed in the stability branch and cherry picked over to the main branch. It is not ideal but it seems to work acceptably especially with so many developers working on the same code base. Of course, our code is for embedded systems and so it is a little different to what you describe.
-
SkysTheLimit wrote:
we schedule regular 'stability points' that serve as snap shots and used for testing etc
Sounds good but where do you test these stability points? At local or development server?
We make a separate git branch for each stability point and deploy the code to several development benches for testing. One challenge of doing it this way is that some things that are found in a stability point may already be fixed in the master branch and so it takes a little extra time to go through the issues to verify that's the case. It also means that you may end up fixing the issue in both branches but with git, the cherry-picking seems to work quite well.
-
Hello All, We are in the process of reviewing our source control and the way we integrate. Currently we are using SVN but not using it's merging feature etc. All the basic ones like getting latest, commit, put etc. But our team has now increased and quite often two developers end up over writing each others code. Our environment looks like - Test server - where development happens and sit till the functionality is approved Live server - Once functionality is approved and tested, it goes to live (production) server. So my questions are: 1. What do you recommend - svn or GIT or svn is completely fine as long as we use all the features. 2. Should we really be developing in local and then pushing to test server and then production or what do you recommend? 3. Any other tips to automate this process? Thanks
-
HobbyProggy wrote:
Never heard of LOCKS
Yes, I very much know about locks but you can only lock it at SVN level not server level. Right? If tom, dick and harry lock few files then I can still push the file to test server and to production after making changes to it? So it doesn't help.
HobbyProggy wrote:
possibility to communicate with each other
That's what we are doing now which takes up lot of time. So need a better solution. Hope you got my point smarty pants? :)
cp-andy wrote:
push the file to test server and to production after making changes to it
Without going through a build/test/QA phase? That's nuts! This is a process problem, not a source control problem!
Decrease the belief in God, and you increase the numbers of those who wish to play at being God by being “society’s supervisors,” who deny the existence of divine standards, but are very serious about imposing their own standards on society.-Neal A. Maxwell You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun