1. Automated build after each CVS checking operation
Yes, running an automated build with every commit to the version control repository for a project (e.g. CVS, in your case) and receiving feedback is, on the surface, "Continuous Integration". However, it's important to know what is in the "automated build" to determine the benefit you are getting from the process. Is this automated build running automated tests, is it rebuilding your database, is it deploying the software to a target environment? The more you can verify that you have "working" software, the better (while keeping the build fast for rapid feedback). Even if it's simply a clean compile every time someone makes a change, it's a start toward getting more benefit from a CI system.
2. Do a nightly back up build.
I'm not sure exactly what you mean by a "backup" build, but I will assume you're referring to a "nightly build", in general. A nightly build can be a good thing, but it's not continuous integration. Some teams choose to run a fast "commit" build with every change and then run either a secondary build (immediately after a successful commit build) or a periodic/nightly build to run slower-running processes such as security analysis/performance
testing which might take quite a bit longer. Let me know if you mean something else by a "nightly backup build".
[ August 27, 2007: Message edited by: Paul Duvall ]