NAnt Best Practices
Here are a few helpful hints I have compiled from my experience with NAnt:- Isolate destructive clean targets and constructive setup tasks.
- Use single quotes around XML attributes to allow double quotes to be embedded for command-line parameters.
- Everything hinges on your directory structure. Depending on your SCM system, changing this in the future might be painful, so put some thought into it now.
- Although NAnt can integrate with most SCMs (such as Visual Source Safe, CVS, and others), use a script to check out the build scripts. This allows the build scripts to reside in a convenient repository and more importantly to be under Source Control themselves. Use the SCM for checking in and labeling.
- Standardize on a version of NAnt. The easiest way is to store the build tools also in Source Control. This would allow the entire team to use the same version of the build, and all will upgrade at the same time. Nothing is worse than trying to debug a build problem only to find out a person was using the wrong tools or an old version of the build. Use the nant.version properties.
- Separate the deployment version of NAnt from any development versions of NAnt.
- Use the nant.settings.currentframework property to ensure that the proper version of the .NET runtime exits on the target machine. If the proper version of the .NET runtime is not there, fail the build, but have this functionality as a configurable command-line property.
- For large projects with multiple sub-projects, use a standard set of targets.
- Use a properties file.
- Run your build and upgrade NAnt often. This allows the maintenance work for Unit Tests and makes keeping synchronized with NAnt changes a small task.
- Use the replace task to increment build numbers.
- Use the SMTP task to email build results.
|
لطفا منتظر باشید ...
