Software Engineering at Google Chapter #18 - Build Systems and Build Philosophy (1 of 3)

  • Build systems should be fast and correct
  • Builds can happen automatically when someone submits changes to a repo
  • Tests should be run as part of the pre-merge build. This allows developers to fix things before they are merged as to not “break the build” for everyone
  • Pipelines can be created so that changes to repos are built, tested, and pushed to production without human intervention
  • In a similar vein, you can create stopping points within the pipeline where human approval is required (code review before merging into master or security sign-off before pushing the code to production)
  • Managing code is easy, managing software dependencies is hard
  • Dependencies can be defined as…
    • Tasks (gather some configuration data and apply it to the build process)
  • Artifacts (gather binaries that will be used in the build process)
  • Libraries (install all libraries that the build needs)
  • External (can the testing process talk to an external data source?)
  • The build system manages all of these things
  • Old style build systems are simple scripts that build the software and nothing more (no dependency management, no version control, no testing, no concurrency, etc)
  • Modern build systems use build-files instead of a script
  • Build files define a series of actions or steps or tasks necessary to build the software
  • Build files are modular so you can re-use them across projects
  • < BACK NEXT >



    Thank you for your time and attention.
    Apply what you've learned here.
    Enjoy it all.