Continuous Integration with 22Yards
There are many aspects in making a great product even better. But in this blog post, we would like to discuss about one specific point ? Continuous integration. CI is an unsung hero, but the job of CI is to remain in background and hide as much details as possible. This blog is definitely not a gyan session about the continuous Integration itself but some ideologies behind the implementation at DET Labs and an XNA project.
Our game uses XNA framework 4.0 among other things. XNA is not a game engine, but a Framework. When the development started, it consisted of couple of projects. In due course it has grown to about 37 projects, implementing different modules all interacting with each other. Not to mention additional projects covering the test framework. So how can a One-man army handle this? Well, for small projects use Visual Studio to develop and link all projects to one solution. keep the complete solution in a safe folder, continually back it up etc..Another developer might host the code in a Source control.and keep checking it in at necessary intervals, so that he can track all changes and revision.
How do you tackle scenarios, where you start assigning separate projects to different developers, Test Developers etc.? Obviously it?s a good sign that you are expanding. But what does the workflow look like now? Where do you run the 10s of thousands of test cases? Imagine all developers running test cases on their development boxes and then committing. Imagine fixing a single line of code and for that opening up the entire solution, making the change, running the Unit tests and then checking in. Isn?t this a waste of time? It is, for most scenarios and more importantly for our scenario. Another scenario is where you deploy often. How do you package this and deploy? What if you want to keep an archive of Daily/Monthly builds? These are age-old questions and this is an age old problem which fortunately is solved pretty fairly with the help of Continuous Integration. CI is not a tool, but a process to be precise.
So here is how we are going to streamline our task at hand.
1) Have a central Source code repository ?> For our centralized needs we are using SVN. So all check-ins goes to svn server.
2) Automate Code Analysis and Code compliance policies at Central server. ?> We ought to place quality gates. If the code that?s checked-in doesn?t meet the coding bar, then its not going to be built. Let?s notify the guy who checked-in and rectify that.
3) Automate Build process on Central server/Run Tests on Central server. ?> Let?s decouple the tasks. Let tests be run on server (for example on any change detected to Source). Let the build be done on the server. So that for a developer all he/she needs to do is, write proper code as per Specifications. Rest all is taken care in the hindsight. This way we also get a loosely coupled Test and Dev framework.
5) Notify build breaker in case Build breaks or test fails and do post build stuff (lets say, revert to previous successful build, notify which test failed etc.). Every member in the project team need not panic on build failures.
6) If all steps complete successfully,archive the package or deploy it.
7) With all this, still allow Developers/Testers to have their own copy of project which they can build on their machine (for example, if they are trying to give a private instrumented binary to customer or test it out ourselves).
With around 4 days of relentless work and lot of study about our precise requirements and various offerrings, this is what we have achieved so far.
1) Continuous Integration with our main project using open source CruiseControl.net
2) Automated Builds for each Project using free MSBuild
3) Automated Daily Builds for Main project.
3) Automated Builds for Depending and Dependent projects.
4) Auto notification of Builds Success and Build Failures using hMailServer.
5) Our Custom versioning of DLLs and EXEs.
6) Auto Archiving of Daily Builds to separate Server
7) Automatic BugID URL generation for each build that is caused by a Code change which is associated with a Bug ID (3 Level Indirection) using BugNet URL.
This was an eventual step that we can?t do away with and this is a big step in ensuring that time is saved, manual work is automated and quality is not compromised. This small investment of time will save us tons of time and money. There are couple of key things that are left to be implemented, like Integrating our Test Framework in CI and Post-commit Code Analysis. These are work in progress but hoping to complete them sooner rather than later.
Note: The guy who implemented all this would be sharing his adventures in his blog post too, so check that out for the nitty-gritty.
