Github user drigodwin commented on a diff in the pull request:
https://github.com/apache/brooklyn-docs/pull/93#discussion_r71319147
--- Diff: guide/yaml/blueprinting-tips.md ---
@@ -54,26 +69,64 @@ container (i.e. no install artifacts from previous
runs), while taking advantage
of starting containers.
-### Caching Install Artifacts
+#### Local Repository of Install Artifacts
To avoid re-downloading install artifacts on every run, these can be saved
to `~/.brooklyn/repository/`.
The file structure is a sub-directory with the entity's simple name, then
a sub-directory with the
version number, and then the files to be downloaded. For example,
`~/.brooklyn/repository/TomcatServer/7.0.56/apache-tomcat-7.0.56.tar.gz`.
+If possible, synchronise this directory with your test VMs.
+
+
+#### Re-install on BYON
+
If using BYON or localhost, the install artifacts will by default be
installed to a directory like
`/tmp/brooklyn-myname/installs/`. If install completed successfully, then
the install stage will
-be subsequently skipped. To re-test the install phase, delete the install
directory (e.g. delete
-`/tmp/brooklyn-myname/installs/TomcatServer_7.0.56/`).
+be subsequently skipped (a marker file being used to indicate completion).
To re-test the install
+phase, delete the install directory (e.g. delete
`/tmp/brooklyn-myname/installs/TomcatServer_7.0.56/`).
Where installation used something like `apt-get install` or `yum install`,
then re-testing the
install phase will require uninstalling these artifacts manually.
+## Monitoring and Managing Applications
+
+Think about what it really means for an application to be running. The
out-of-the-box default
+for a software process is the lowest common denominator: that the process
is still running.
+Consider checking that the app responds over HTTP etc.
+
+If you have control of the app code, then consider adding an explicit
health check URL that
+does more than basic connectivity tests. For example, can it reach the
database, message broker,
+and other components that it will need for different operations.
+
+
+## Writing Composite Blueprints
+
+Write everything in discrete chunks that can be composed into larger
pieces. Do not write a single
+mega-blueprint. For example, ensure each component is added to the catalog
independently, along
+with a blueprint for the composite app.
+
+Experiment with lots of small blueprints to test independent areas before
combining them into the
+real thing.
+
+
+## Writing Entity Tests
+
+Use the test framework to write test cases. This will make automated
(regression) testing easier,
--- End diff --
Link out to the YAML testing section
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
