This post is the second part in the series about my pet project, and this is about automating stuff.
As I already mentioned, I want my personal project to be automated as much as it makes sense. That starts with automatic builds whenever I check in some new code, automated testing starting with unit testing, later integration testing and then, last but not least, automated UI testing and of course code coverage analysis while testing.
To be able to do the automated UI testing, I need the UI to run somewhere to test, so that will include automated deployment to one or more test environments.
I also want to automate the process of creating beta and of course release builds. If I'm going to release binary packages to the public, I also need to package them up in some sort of installer or NuGet packages. So when I start with that stuff, I'm going to automate that too.
Some of you might ask why I'm so bought in automating all that stuff and putting so much work in the backing infrastructure when this is 'just a pet project'.
Well, there is mainly one reason: All those tasks are in fact pretty tedious, like running the whole test suite before committing, building, packaging up and deploying the project etc.
When I work on this project, I want to concentrate on the actual work, like getting things to work like I want them to work, see what I just did and not spent a lot of time on some boring and also error-prone tasks.
So I feel that every minute I spend for my infrastructure will pay for me later in the project. That is also why I'm going to chose my environment carefully and evaluate some products. More on that in my next blog post, where I want to introduce the build server and bug tracker's in my first evaluation round. I also want to explain to you the important things that those tools need to be capable of - of course in my personal point of view and for this very pet project.
Continue with the next part, or see the other parts in this series:
[contentblock id=infrastructurelinks]