anchor.diff:    `bosh generate package libyaml_0.1.4`
   
   You now have package skeletons for all the dependencies in your release.
  +
  +View the package skeletons with `tree`:
  +
  +<pre class="terminal">
  +$ tree packages
  +packages
  +├── libyaml_0.1.4
  +│   ├── packaging
  +│   ├── pre_packaging
  +│   └── spec
  +└── ruby_1.9.3
  +    ├── packaging
  +    ├── pre_packaging
  +    └── spec
  +
  +2 directories, 6 files
  +</pre>
  +
   Later on, you will flesh out the skeletons to make them usable packages.
   
  +**Note**: Use of the `pre-packaging` file is not recommended, and is not discussed in this tutorial.
  +
  +### <a id="..."></a> Create packaging scripts ###
  +
  +The packages you have been creating represent software that BOSH needs to
  +install on VMs at deploy time.
  +That is accomplished by the `packaging` script within each package.
  +
  +Every packaging script must install the software for the package it belongs to,
  +and also invoke any package dependencies.
  +Use your dependency graph to determine which dependencies belong in each
  +packaging script.
  +
  +For a start on writing packaging scripts, study the examples.
  +Begin packaging scripts with a `set -e -x` line to aid debugging at compile and
  +deployment time.
  +
  +_explicitly say to write all packaging scripts now?_
  +_include packaging scripts inline?_
  +
  +### <a id="..."></a> Create packaging specs ###
  +
  +Within each `packaging` directory is a `spec` file which states:
  +
  +* The package name.
  +* The package's dependencies.
  +* The location where BOSH can find the binaries for the package.
  +
  +Use your dependency graph to determine which dependencies belong in each spec.
  +
  +Follow this convention for describing binary locations in the `files` block of the spec:
  +
  +* Find the official site for the binary in question.
  +For example, Ruby might be at `http://cache.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.gz`.
  +
  +* Download the binary from the official location and make sure the md5 hashes match.
  +
  +* Record the binary name including version number, with a slash and the binary filename concatenated to it.
  +In the same line, cite the official URL in a comment.
  +
  +BOSH interprets the locations you record in the `files` section as being in the `blobs` directory.
  +In the next few steps, you will add the actual blobs to a local blobstore, which will populate the
  +`blobs` directory with the correct information.
  +
  +Observe how these conventions are followed in the examples.
  +
  +_add examples inline?_
  +
  +_can't remember how we came up with the gemfiles and such_
  +
   ## <a id="..."></a> Add Blobs Locally ##
   
  -When creating a release, you use git for your source code.
  -Git is not well-suited to dealing with large binaries, however.
  -For this reason, you add blobs to a local blobstore while creating
  +When creating a release, use Git for your source code.
  +Since Git is not well-suited to dealing with large binaries,
  +blobs should not be checked into Git.
  +
  +Instead:
  +
  +* Add blobs to a local blobstore while creating
   dev releases.
  -
  -Before you create a final release, you typically upload the blobs to a public blobstore.
  +* Upload blobs to a public blobstore before you create a final release.
   
   ### <a id="..."></a> Decide what blobs to add ###
   
  -* running `bosh add blob` now would fail with an error
  +Normally, all the binaries you record in your packaging specs should be added to a local blobstore.
  +
  +_remark about how this is a decision?_
   
   ### <a id="..."></a> Create a local blobstore  ###
   
  -* in `config` folder: `final.yml` and `private.yml`
  +The `config` directory (of which there is only one per release) is where you record the information
  +BOSH needs to create a local blobstore and pull in the proper binaries.
  +
  +* The `final.yml` file names the blobstore and declares that it is local.
  +* The `private.yml` file specifies the path of the blobstore, along with a secret.
  +
  +The `config` directory also contains two files whose content is automatically generated:
  +the `blobs.yml` file and the `dev.yml` file.
  +
  +Adapt the example `final.yml` and `private.yml` files to fit the specifics of your release.
  +
  +_insert examples_
  +
  +Note that `final.yml` and `private.yml` essentially divide up a small amount of content.
  +At some point in the release creation process, `private.yml` may contain keys.
  +For that reason, it is automatically gitignored (assuming you used the `--git` option when
  +running `git init release` at the beginning of this tutorial), so its contents truly
  +remain private in that they are not checked into Git.
  +
  +The "secret" in `private.yml` file is "does not matter."
  +The reason is that the `secret` line, while required, is deprecated, so its content actually
  +does not matter.
   
   ### <a id="..."></a> Add blobs to blobstore ###
   
  
positive.code: 
  ### <a id="..."></a> Upload blobs ###
  
    `bosh upload blobs`
  
  ### <a id="..."></a> Release ###
  
    `bosh release --final`
  
  
  ## <a id="..."></a> Test the Final Release  ##
  
  
  
  
  
  
  
  
negative.code: 
  Suppose you want to create a BOSH release of an application that you have developed.
  
  You can do this using an iterative workflow:
  
  1. Develop the application.
  1. Create a **dev release**.
    * BOSH bumps the release number by a "dot."
  1. Deploy the **dev release** to your test environment.
  1. Test the **dev release**.
  Is it ready for final release?
      * If the answer is no, begin the cycle again.
      * If the answer is yes, continue.
  1. Create a **final release**.
    * BOSH bumps the release number by whole number.
  
  Beside the workflow, this tutorial explains principles to
  keep in mind when creating BOSH releases:
  
  * BOSH releases do not necessarily depend on the internet.
  * BOSH releases remain buildable for a long time.
  * BOSH releases package up all dependencies.
  * BOSH releases do not add blobs to GitHub.
  * Using underscores in filenames is the BOSH way.
  * Commenting your code to facilitate debugging is the BOSH way.
  
  ## <a id="..."></a> Decide What to Release ##
  
  Some releases contain a single app.
  Others are collections of the pieces of software that together form a particular service.
  For example, such a collection might include a few MySQL nodes along with a dashboard app.
  You might think of each of these pieces of software as an area of functionality, or a feature.
  In a BOSH release, each such piece is a _job_.
  
  In a BOSH release:
  
  * **jobs** describe pieces of a service.
  * **packages** provide source code and dependencies to jobs.
  * **src** provides non-binary files to packages.
  * **blobs** provides binaries not checked into GitHub.
  
  What to include in a release is a judgment call, especially for more complex distributed software.
  
  This tutorial walks you through creating a dev release and then a final release
  that contains a single job, namely a Sinatra app called `ardo`.
  
  ## <a id="..."></a> Create the Release Directory ##
  
  The _release directory_ is where you run all the BOSH commands needed to create a release.
  Create the release directory:
  
    `bosh init release ardo-release --git`
  
  The `--git` option initializes a git repo in the release directory.
  This is recommended but not required.
  
  `cd` into the release directory and view the release with `tree`:
  
  <pre class="terminal">
  $ tree .
  .
  ├── blobs
  ├── config
  │   └── blobs.yml
  ├── jobs
  ├── packages
  ├── src
  └── ardo-web
  
  6 directories, 1 file
  </pre>
  
  ## <a id="..."></a> Create the Job Skeleton ##
  
  For each piece of software you include in a release, you create a job.
  
  When you first create it, the job is a _skeleton_: an empty structure to be filled up
  as release creation progresses.
  
  The example release only includes one job.
  
  Generate a job skeleton:
  
    `bosh generate job ardo-web`
  
  Naming the job `ardo-web` distinguishes it from the original app.
  
  View the job skeleton with `tree`:
  
  <pre class="terminal">
  $ tree jobs/ardo-web/
  jobs/ardo-web/
  ├── monit
  ├── spec
  └── templates
  
  1 directory, 2 files
  </pre>
  
  ### <a id="..."></a> Create a control script for the job  ###
  
  Every deployed app must have a way to start and stop.
  A control script serves that function in our example.
  In a BOSH release, a script is an ERB template
  stored in the `templates` directory for the relevant job.
  At compile time, BOSH transforms templates into files which
  eventually reside on the VMs where the deployed software runs.
  
  For our example, the control script includes a start and a stop command.
  Further details would be beyond the scope of this tutorial.
  Writing scripts is typically one of the heavier tasks entailed in creating a release.
  Real-life software typically needs more functionality than just start and stop,
  so the scripting is more extensive than in this example.
  As you discover unexpected behavior while testing your dev releases,
  you refine your scripts and iterate.
  
  For now, create the control script and save it as `ctl.erb` in the `templates` directory.
  
  ### <a id="..."></a> Update the job spec  ###
  
  The `spec` file is the home for metadata about your job.
  
  You now possess two pieces of information which must be recorded in that metadata.
  
  1. When the software is deployed, the `ctl.erb` template should become
  a file on the VM.
  Its path on the VM should `bin/ctl`.
  
  1. Since there is an `ardo_web` job, you know that an `ardo_web` package must be created
  sooner or later.
  
  In the `spec` file, edit the `templates` and `packages` blocks to reflect this information:
  
  ~~~yaml
  
  templates:
    ctl.erb: bin/ctl
  
  packages:
  - ardo_web
  
  ~~~
  
  ### <a id="..."></a> Commit ###
  
  You have now created a job skeleton.
  If your release includes several jobs, go back and repeat this process for each one.
  
  This is a good time to commit.
  Be aware that if you followed the recommended practice of using the `--git` option with
  `bosh init release`, the correct `.gitignore` file has been automatically created for you.
  
  ## <a id="..."></a> Create Dependency Package Skeletons ##
  
  A BOSH release contains one package for each of its jobs,
  and additional packages, one for each dependency.
  To see clearly what packages you need to create,
  start by making a dependency graph.
  
  