The build process

The build process

  • Ensure Binary Integrity of your build:
    • The build either works or it does not work. This way it is easier to rule out errors in different layers of the project like database or logic
  • Builds are obtained from files under source control:
    • This means that if a problem happens the error can be linked to a specific commit or tag under version control
  • Build can happen remotely (production) or locally:
    • This allows for the same local configuration to be tested on different environments remotely (production)
    • It can also allow specific special configuration (ex: a tag under version control) to be propagated to production
    • Basically helps prevent configuration errors by removing as much as possible the human aspect
  • All builds should contain a database script (under version control) that creates/restores the database¬† from scratch
    • This way each database change is linked to a version under version control and errors can be linked to each build
    • Also this makes finding bugs a lot easier as they are easier to reproduce
Inversion of Control

Inversion of Control

If you are building an application that has a lot of modules and those modules can be plugged in dynamically then you will probably want to use inversion of control (IoC).

What can inversion of control do for you?

  • help you deal with the configuration of all the modules
  • a one “single point change” so you wont have to hunt down every other place where things could go wrong
  • help with transparency as you just have to use a module and not worry how it is implemented
  • provide a nice way to have strong contracts (due to interfaces)
  • finally, the application can change it’s own behavior when it believes it is necessary at runtime

If you want to learn more I would recommend reading the the famous article written by Martin Fowler.