Why Is Continuous Integration Important

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily. Each integration is verified by an automated build to detect integration errors as quickly as possible. 
Most teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. By doing this teams have found that fewer errors occur in their live environment, so users get more confident in their IT department, trust is a very valuable commodity, not easily bought but easily sold and lost.


Developers get to understand quickly where their code may break someone else's, so development does become quicker, but only after the pain is endured to get your codebase to an understandably coherent state.


Continuous Integration cannot be practised in isolation, it must be accompanied with requirements gathering, proper development life cycle to ensure quality of code produced, tested and documented. 
If requirements gathering isn't done correctly, its like building a house with no foundations, building code on something that is not properly understood. Also once the code is made the testers should test specifically on what the requirements were, plus regression testing.
If code isn't quality checked, the most efficient way of coding won't be created and understanding of your codebase shared amongst your team, if code isn't tested well: well it's obvious that the code won't match the requirements gathered, who should test: well do you get your butcher to give you legal advice, no, so you should have qualified testers who understand quality testing, testing can be a thwart relationship between developer and tester, testers understand this and manage the relationship, isn't documented creates a situation whereby future development doesn't understand why previous development was done, so the developer changes the code to what should be best practices only to realise that he has affected another part of the system; this wastes time and causes the users to have less faith in the IT department, only because documentation wasn't done correctly.


This is the minimum, there is more, such as source control.


Yes all of this slows down development, which affects the time to roll-out new projects, but it means that the code being developed is quality and is managed correctly. If the above isn't done developers won't understand and know what is in their live system, so how do you know what is important and what isn't and changing anything can and will have knock-on-effects to other related undocumented parts of the system.


The lesson is, if you aren't doing the above now don't wait until things go wrong, don't be a reactive development department, become proactive and solve the problems now before they do cause problems.

Get Prepared For AppExchange

http://wiki.developerforce.com/page/Security_Review
This page covers things like costs of submitting to AppExchange and important links to test your code to get it ready for the AppExchange

Free testing tools to check your code is written well

http://security.force.com/webappscanner
http://security.force.com/sourcescanner

Of course you can use these tools not just for preapration for the AppExchange but for all your projects

I'm currently working on an App to allow you to document the class references made throughout your codebase so that a class structure diagram can be produced from the output, and for a deployment procedure to be automatically produced by selecting your classes, objects and pages that you want to deploy.
If you would like to have this please contact me.