Friday, December 21, 2007

sql, source control, and continuous integration

Well the new gig has given me a chance to set up something form scratch...

The pieces?
Suberverion - code repository
Cruise Control .Net - continuous integration
MSBuild - scripted builds

The hitch? A good portion of code will be in SQL because of the nature of the product. (Working with comparing large amounts of data, stuff like that.) So I want to make sure the team can actually track edits to the variou stored procs in such.

Step one:
In Visual Studio set up a dbproj and import the needed schema.
Next on the project properties set up two types of build. One as a local "dev" build so that the developer can test locally. The other as a build targetting the "test" server. Make sure that the two types of build have different names for thier script files.

Step two:
Test the builds from the command line using MSBuild. Make sure everything is going where it is supposed to go.

Step three:
Add source control. Set up Subversion where ever you like an then check in the Db Project with all it's files. Now you have source controlled sql.

Step four:
Cruise Control .Net... I'm still setting this up but the goal would be something like...

Developer Tasks:
1. Performs "get latest"
2. Rebuilds the system locally
3. Edit/add what ever is needed
4. Creates/performs unit tests
5. Once happy with code, checks the code into Subversion.

Cruise Control Tasks:
6. Sees that Subversion has changed
7. Gets the latest code
8. Builds the code
9. Deploys the code to the test server

From that point I'm still working out how and where to automate the test process.

But if this works I can bring the db development side in line with the regular coding side. Then all the team will have to worry about is doing actual work as opposed to the repetitive side of developing...

0 Comments:

Post a Comment

<< Home