6

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.

Ville M
  • 2,009
  • 7
  • 30
  • 45

8 Answers8

7

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.

Michael
  • 54,279
  • 5
  • 125
  • 144
3

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

starblue
  • 55,348
  • 14
  • 97
  • 151
1

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.

Nick Berardi
  • 54,393
  • 15
  • 113
  • 135
  • added info 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. – Ville M Apr 14 '09 at 23:23
1

My number one item:

  • Update often, commit often,

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

Dirk Vollmar
  • 172,527
  • 53
  • 255
  • 316
  • 1
    Reading through the comments of that blog entry, you will find that I disagree with that sentiment strongly. Revision control systems are intended to control revisions of software, not to back up intermediate edits. A good editor should do that for you. (version-control in Emacs) – T.E.D. Apr 14 '09 at 22:09
  • Well, that's a lengthy discussion and I honestly didn't read it because I could not find any relevant new points after a few comments. – Dirk Vollmar Apr 14 '09 at 22:49
1

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)
Stefano Borini
  • 138,652
  • 96
  • 297
  • 431
0

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

jdecuyper
  • 3,934
  • 9
  • 39
  • 51
0

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:

  • When to check-in (daily, weekly, more often, less often)
  • When builds are done (daily, weekly, etc.)
  • Use of dual repositories (engineering vs production)
  • Allow binaries in repository
  • Allow third party software in repository
  • All items necessary for build in repository
  • When imports or commits to trunk are done
  • Use one file to export and build
  • Allow check-in with/without bug report information
  • Enforce 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.

RePierre
  • 9,358
  • 2
  • 20
  • 37
Mark
  • 1,368
  • 5
  • 13
  • 26
0

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

RN.
  • 997
  • 4
  • 14
  • 31