Classification of software output

I work on software projects which involves lifecycle spanning from understanding requirements, developing software, creating production infrastructure, operating and supporting the software. There is enough software work done in these projects that I need to framework for understand what all I do. Classification is an important part of making things small and hence coherent.

If I go back to earlier work life my responsibility used to end with developing the software which was completely tested. More recently with responsibility of operating the software my team writes I have learnt there is another development, development of application execution environment. Now all that is left in between application software and execution environment is a deployment of former onto later. But I am also aware of the fact that application development is more than writing just production code. So long story short I ended up with following classification which I find useful.

Application

Production code, built-in diagnostics, database upgrade/rollback scripts, application configuration

Delivery tools

Unit tests, integration/functional tests, performance tests, build, continuous integration, deployment scripts, testing stubs

Execution environment

Operating system configuration, hardware/network configuration, monitoring, application data maintenance, application data backup

I have found this classification useful in dividing my codebase. The most obvious thing would be breakup the code repository completely on these lines, but some exceptions are worth here. This is based on the development culture which has worked for my teams and you might choose to do them differently, for good reasons.

• We keep unit tests and integration tests in application code repository as write unit tests in tandem with writing production code.
• I prefer keeping functional tests separate from application to ensure that they are not dependent in anything in the production code. I like them as black-box as possible.
• Since I have been in operations I appreciate applications which tell me about their health in production themselves. Hence diagnostics in application repository.
• Since we run build before committing the code so we keep the build scripts with the application.

Independent codebases lend themselves much better for independent teams, part of the same project, working on them.