--- title: "Planning a daily, automatic build" url: "https://osherove.com/blog/2004/6/4/planning-a-daily-automatic-build.md" canonical: "https://osherove.com/blog/2004/6/4/planning-a-daily-automatic-build.html" published: "2004-06-04T08:30:00" updated: "2004-06-04T08:30:00" tags: [".Net Original"] author: "Roy Osherove" description: "One of the tasks I'm facing at a project these days is coming up with a automatic build configuration for the project. the idea is having a “daily build” for an existing project which comprises of roughly 110 sub…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Planning a daily, automatic build By Roy Osherove June 4, 2004 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published June 4, 2004; technical details may be outdated. One of the tasks I'm facing at a project these days is coming up with a automatic build configuration for the project. the idea is having a “daily build” for an existing project which comprises of roughly 110 sub projects (imagine loading **that** solution in vs.net!). It is quite fun. Like solving a big puzzle. Here's a little about what I envision. Feel free to comment. **The tool:** The automatic build tool that we Will be using is [FinalBuilder](https://osherove.com/blog/2004/6/4/FinalBuilder). It has roved itself in many areas I've seen, including some of the most [respected](http://www.larkware.com/) [members](http://www.joelonsoftware.com/articles/fog0000000023.html) in the community that use it on a daily basis. _Why not the free tools out there?_ Let's face it - MSBuild, NAnt and all their friends, unless I'm mistaken, are pretty sucky in the visual development and maintenance department. I made a promise to myself I won't do manual XML editing unless I am forced to by gun point or a salary decrease. Neither has happened. yet. **The architecture:** A build server A source control server A backup server A testing server A staging environment (multiple machines imitating the machines at the production location) A remote staging environment(less machines but more similar security restrictions). **In broad strokes a daily build would mean:** The build server takes out all source control from source  control build it all (including all versions, debug and release) Back up to zip files using incremented version ,date and time into the backup server Deploy automatically onto the testing machine all the part of the distributed application in question, allowing the team to run smoke test on the built application. However, there are more processes. After smoke testing and more rigorous tests, another automatic script will deploy a version into the staging server. It Will use the backed up zip files from the back up server for this. Load testing and others will performed on the stating servers. After that another automatic deployment will take place - onto the **remote** staging servers. These serves sit in the same place as the real production ones, and so enjoy the same security benefits , meaning we can test what happens behind the real firewall and active directory and all that. Once tests have passed there, we can use another auto deploy into production. These are the basic steps. It's pretty fun planning this, kinda like building your own big ant farm. One of the biggest issues we are facing and still haven't solved is this: Databases. In many cases, making a new release might mean just a few changes on the database data, and nothing more. There needs to be a way to get just those changes from the dev DB and into the test DB, automatically. It gets a little tricker. We also want the database to be backed up along with each version's source files into the backup server. A binary backup will do in some cases (multiple databases here, but some databases need to be retained only in schema and not in binary form. certainly this will prove to be the biggest challenge in this process. I'd be interested to hear how other people get around this problem. ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Jun 4, 2004 ### [VB is rubbish? rubbish.](https://osherove.com/blog/2004/6/4/vb-is-rubbish-rubbish.html) - Jun 4, 2004 ### [Solving weird problems, and making others solve them as well](https://osherove.com/blog/2004/6/4/solving-weird-problems-and-making-others-solve-them-as-well.html) - Jun 4, 2004 ### [More discussion about MS and agile methodologies](https://osherove.com/blog/2004/6/4/more-discussion-about-ms-and-agile-methodologies.html) - Jun 4, 2004 ### [Managed Smart Documents Wrapper](https://osherove.com/blog/2004/6/4/managed-smart-documents-wrapper.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/