What are source control and configuration management best practices?

Question

I am thinking of a list that I could refer other developers to with things like:

1. One build script, such as makefile, will build and test entire project
2. All components to needed build the system need to be source controlled

Anybody have such a list? In priority order?

---

UPDATE - added some fyi detail

System in question consists of C++ and makefiles, Java with ant that results in WARs, as well as powerbuilder and C# gui components. All code is in perforce.

So I am looking for both generic as well as language specific best practices.

Answer 1

To me, the #1 rule is this:

The main branch is sacred - it must always be buildable, capable of passing BVT's, and be basically usable.

Any code that is allowed to go into the main branch that causes a build or BVT break exposes a bug in the process. The process should allow buddy builds/tests for single branch systems, or require child branches to build and pass BVT's before mergining into the main branch, or other such safeguards.

Answer 2

This is highly dependent on what environment are you building in?

• Is it C/MakeFile?
• Is it Java/JUnit/Ant?
• Is it .NET/NUnit/NAnt?
• Is it .NET/MSUnit/MSBuild?
• Is it Ruby...
• Is it Python...
• Is it PHP

Each of these differ in approach and setup. So we need to know your setup before you can be helped.

Answer 3

My number one item:

• Update often, commit often,

or, as Jeff puts is: Check In Early, Check In Often.

Answer 4

If you pass those questions from the "Joel Test", you should be on the right path:

Do you use source control?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?

My #1 is : Can you make a build in one step?

The Joel Test

Answer 5

Being an SCM manager, the best answer that I can give you on this question is "it depends". Your list and order of importance of items on the list will depend on your project requirements, language you are using, and developer level.

One thing that you may want to consider to me important (or #1) on ANY list you put together is that the trunk or primary branch of your tool be VERY heavily controlled and only a very select few have access to import or commit changes to it. This will save a ton of headaches at release time.

Items that can be on any list you put together is:

• List itemWhen to check-in (daily, weekly, more often, less often)
• List itemWhen builds are done (daily, weekly, etc.)
• List itemUse of dual repositories (engineering vs production)
• List itemAllow binaries in repository
• List itemAllow third party software in repository
• List itemAll items necessary for build in repository
• List itemWhen imports or commits to trunk are done
• List itemUse one file to export and build
• List itemAllow check-in with/without bug report information
• List itemEnforce check-in comment standards

The list can go on and on depending on your specific requirements, but I think you get the general idea with what's here.

Answer 6

The system must build by itself, test by itself, and download+build dependencies by itself. I have a makefile downloading, building and deploying a runtime environment which is "certified" for my trunk version. This makefile is committed as well into the repository.

Remember to commit another, very important, and mostly overlooked thing (comes in a bundle of three):

• The SQL code that creates your database layout (put a version on it!).
• The SQL code that brings up your database layout version (to upgrade)
• The SQL code that bring down your database layout version (to downgrade)

Answer 7

The whole process of "getting the latest" and "building" should be smooth, easy ,fast and reliable.

If not- developers tend to skip getting the latest and keep on working on their stale copies and that is something you want to avoid.

This is more or less what Michael said- but I want to stress that beyond the branch being sacred and stable- the whole process should be quick and easy

Kinda like Google's philosophy that downloads\installations should be quick and easy

Answer 8

Take a look at High-level Best Practices in Software Configuration Management.