Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Build Process 2.0 Goals by Mind Map: Build Process 2.0 Goals
0.0 stars - 0 reviews range from 0 to 5

Build Process 2.0 Goals

Runnable on any dev host

Trivial setup process: no manual config

Install daylife-vendor, All build dependencies (code) in daylife-vendor

"svn co trunk"

"make config", Foreach project: config

Any developer can (re)build a deployable set of RPMs

No state in an external DB

"Usable on an airplane"

State in SVN, current release number, ???, SVN revision number

Small set of top-level tasks to use repeatedly

"make rpm", Foreach: build + package

"make install", Foreach: install into virtualenv

"make test", Run tests against virtualenv

"make clean", Wipe build/install artifacts, "realclean" wipes all artifacts

"make lint", Static type analysis, Code style check

Pythonic, but not Python-exclusive

Build types

Pure Python

Python + C extensions

Java

Able to extend for new build types

"pythonic" = leverages Python skills

"pythonic" = looks like pseudocode

Minimal "stuff to remember"

Minimal "magic"

Support Continuous Integration

CI == fast feedback

Run test suite, starting with nothing more than an initial checkout

Wipe ALL artifacts, resetting to "virgin checkout" state

Install into an arbitrary root dir to allow > 1 CI build/box

trunk

other branches

Test output in standard formats

Unit tests -> JUnit XML

Style tests -> ??

Static type analysis -> ??

Coverage report -> Clover XML?

Easy for our team to pick up & stick with

Small number of commands to remember

Same commands work at "project" and "top" levels

"help" command that works everywhere

Easy to apply to new projects

Minimal boilerplate per project

Zero arguments = "right thing by default"

Quick, helpful feedback when used "incorrectly"

Value for all parties

Value for command-line users

Value for Testers, Working CI builds!

Value for Eclipse users, Bootstrap sys.path for debugger usage, Simplifies dev box setup, Developers see same errors as CI, Tie-in with Eclipse's notion of "projects"?

Value for build master (Howard), Kill Howard's need to "edit proc_mgr config", "start/stop config" ships with app, Tech lead maintains the config, Give Howard a way to AUDIT the distributed configs

Value for OPS, Kill Mark's need to "edit Nagios config", "service check" definitions ship with the app, Tech lead maintains the tests, Give Mark a way to AUDIT the distributed test definitions

Support company growth

Will it still work when we have 100 developers on staff?

Eliminate human "single points of failure"

Aim for 10x growth

Don't over-engineer

Allow independent sub-teams

Enforce contracts between teams

Allow "build/test master" roles to be delegated

self-subscribe to test results (subsets)

Coverage reports

Fast feedback for everybody, in every role

Eliminate single points of failure