Skip to content

Instantly share code, notes, and snippets.

@zkessin
Last active August 29, 2015 13:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save zkessin/9744067 to your computer and use it in GitHub Desktop.
Save zkessin/9744067 to your computer and use it in GitHub Desktop.

Some Notes on building packages

Build must be simple

A developer must be able to make a build in one step. Ideally he should be able to type build <> <> and have a build happen with no further intervention. By making the developer only type one command we greatly reduce the chance that a step will be forgotten, done out order or otherwise messed up.

Builds must have semantic versions

We should not refer to a build by a SHA but by a meaningful version number, for example "1.3.2" or "1.3.2RC1" for a release candidate build.

Builds must be consistent

When building a given version we must get consistent results. Furthermore we must be able to say that for each project and version there exists a known SHA1 hash. If version 0.8.6 of the xray_web project when built has sha 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12 then if we try to build version 0.8.6 again three years later it should still give the same sha1.

We may also choose to make incremental builds for test servers, that are not tracked, but these should only be for testing and development, not for distribution to customers.

Build scripts must be considered software

That is to say that they need to be built using git repositories, improvements should come via pull request.

For every project we should have a second "build" repository with a consistent naming scheme. That is to say for the xray_web project the build scripts should live in the repo xray_web_build.

In this repo we should have all the mechanism for doing that build.

We must be able to create a build script quickly

we will use open source erlang packages like boss_db, cowboy, jsx etc. We need to be able to create packages from an open source erlang package that has been built with rebar.

In addition erlang packages tend to have dependencies, for example the boss_db package has 26 external dependencies. (see list)

App Version Url
aleppo TAG bef139e4c7 git://github.com/ChicagoBoss/aleppo.git
bson TAG 6d3cc910ea git://github.com/mongodb/bson-erlang.git
ddb TAG HEAD git://github.com/Concurix/ddb.git
dh_date REV HEAD git://github.com/zotonic/dh_date.git
epgsql TAG 7b6c71e git://github.com/mabrek/epgsql.git
erlando REV HEAD git://github.com/travelping/erlando.git
erlmc TAG HEAD git://github.com/bipthelin/erlmc.git
ets_cache BRANCH boss_branch git://github.com/cuongth/ets_cache.git
gen_server2 REV master git://github.com/hyperthunk/gen_server2.git
goldrush TAG 0.1.6 git://github.com/DeadZen/goldrush.git
ibrowse TAG v4.0.2 git://github.com/cmullaparthi/ibrowse.git
jsx BRANCH master git://github.com/talentdeficit/jsx.git
lager TAG 2.0.2 git://github.com/basho/lager.git
meck BRANCH master git://github.com/eproxus/meck
medici BRANCH rebarify git://github.com/ChicagoBoss/medici.git
mongodb TAG ce9bf77902 git://github.com/ChicagoBoss/mongodb-erlang.git
mysql TAG 16cae84b5e git://github.com/dizzyd/erlang-mysql-driver.git
pmod_transform REV HEAD git://github.com/erlang/pmod_transform.git
poolboy TAG 1.0.0 git://github.com/devinus/poolboy.git
proper REV HEAD git://github.com/manopapad/proper.git
protobuffs TAG 0.8.1 git://github.com/basho/erlang_protobuffs.git
redo REV HEAD git://github.com/JacobVorreuter/redo.git
riakc TAG 1.3.0 git://github.com/basho/riak-erlang-client
riak_pb REV master git://github.com/basho/riak_pb
tiny_pq TAG HEAD git://github.com/ChicagoBoss/tiny_pq
uuid REV master git://gitorious.org/avtobiff/erlang-uuid.git

We need to be able to have a script that can take a rebar.config file and create packages for all the dependent packages.

When creating a release we should clone the repo and apply a named tag to that repo. For example when building xray_web version 0.8.6, all all the included projects should be tagged with the tag xray_web_0.8.6. (in many cases it may be that a given commit could have many tags if the software does not change much).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment