--- title: "Agile Deployment" url: "https://osherove.com/blog/2005/1/11/agile-deployment.md" canonical: "https://osherove.com/blog/2005/1/11/agile-deployment.html" published: "2005-01-11T19:02:00" updated: "2005-01-11T19:02:00" tags: ["Agile Related"] author: "Roy Osherove" description: "Rachel Davies posts about the idea of an Agile Deployment . In an Agile deployment, you have unit tests to make sure that the production system on which your product is installed meets all the required hardware and…" 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/" --- # Agile Deployment By Roy Osherove January 11, 2005 In [Agile Related](https://osherove.com/blog/category/agile-related) **Historical article** · Originally published January 11, 2005; technical details may be outdated. [Rachel Davies posts about the idea of an Agile Deployment](http://www.twelve71.org/blogs/rachel/archives/000666.html). In an Agile deployment, you have unit tests to make sure that the production system on which your product is installed meets all the required hardware and configuration needed. That solves you a lot of trouble, especially is there is a different team in charge on the production server. There's a definite possibility that people are already doing this, though personally I never did (just because I didn't think of such a brilliant idea). What would such unit tests entail? A lot of grudge work, for sure. Especially for complex systems which demand various configurations to appear. I'd suggest to implement the tests, not specifically as unit tests, but using existing automated tools. Here's a list of suggestions: - Create an installer project in VS.NET. An installer can have various prerequisites pertaining to the operating system involved and so on. Create an empty installer project with just the prerequisites and no output. If it fails to run on the production system, you know you forgot something. However, there's only so much you can check in an installer. - You can use an automated build tool such as FinalBuilder and just create lots of "IF" tasks inside it that fail if what you expect is not there. This has the advantage that there are many built in checks in place for you to just invoke. You can also have various actions taken if something is not well. - Create your own custom tool that checks things. You've got two choices here: make it generic enough to be easily customizable for any project(longer time to make, shorter time in the long run) or make one ad-hoc for the specific project.(short time - but re-inventing the wheel every time). - Use a third party tool made specifically for this purpose.  Preferably one that can be run along with your unit tests from the command line. Do you know of any? ## More in Agile Related [All posts in Agile Related](https://osherove.com/blog/category/agile-related) - Jan 18, 2005 ### [Announcing: First Agile Israel user group meeting this month!](https://osherove.com/blog/2005/1/18/announcing-first-agile-israel-user-group-meeting-this-month.html) - Jan 15, 2005 ### [The role of helper frameworks in your tests](https://osherove.com/blog/2005/1/15/the-role-of-helper-frameworks-in-your-tests.html) - Jan 11, 2005 ### [\[Interview\] Jonathan de Halleux on mbUnit and model based testing](https://osherove.com/blog/2005/1/11/interview-jonathan-de-halleux-on-mbunit-and-model-based-test.html) - Jan 6, 2005 ### [Some news from the wild](https://osherove.com/blog/2005/1/6/some-news-from-the-wild.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/