Add development documentation
ADD
CONTRIBUTING.md
+# Contributing to the Datadog Chef recipe
+
+First of all, thanks for contributing!
+
+This document provides some basic guidelines for contributing to this repository.
+To propose improvements, feel free to submit a PR.
+
+## Submitting issues
+
+ * If you think you've found an issue, please search the issue list to see if there's a matching existing issue.
+ * Then, if you find nothing, please open a Github issue.
+
+## Pull Requests
+
+Have you fixed a bug or written a new feature and want to share it? Many thanks!
+
+In order to ease/speed up our review, here are some items you can check/improve
+when submitting your PR:
+
+ * have a [proper commit history](#commits) (we advise you to rebase if needed).
+ * write tests for the code you wrote.
+ * preferably make sure that all unit tests pass locally and some relevant kitchen tests.
+ * summarize your PR with an explanatory title and a message describing your
+ changes, cross-referencing any related bugs/PRs.
+ * open your PR against the `master` branch.
+
+Your pull request must pass all CI tests before we will merge it. If you're seeing
+an error and don't think it's your fault, it may not be! [Join us on Slack][slack]
+or send us an email, and together we'll get it sorted out.
+
+### Keep it small, focused
+
+Avoid changing too many things at once. For instance if you're fixing a recipe and at the same time adding some code refactor, it makes reviewing harder and the _time-to-release_ longer.
+
+### Commit Messages
+
+Please don't be this person: `git commit -m "Fixed stuff"`. Take a moment to
+write meaningful commit messages.
+
+The commit message should describe the reason for the change and give extra details
+that will allow someone later on to understand in 5 seconds the thing you've been
+working on for a day.
+
+If your commit is only shipping documentation changes or example files, and is a
+complete no-op for the test suite, please add **[skip ci]** in the commit message
+body to skip the build and give that slot to someone else who does need it.
+
+### Squash your commits
+
+Please rebase your changes on `master` and squash your commits whenever possible,
+it keeps history cleaner and it's easier to revert things. It also makes developers
+happier!
+
+
+[slack]: http://datadoghq.slack.com

MODIFY
README.md
README.md
@@ -445,3 +445,82 @@ their `CHANGELOG.md` file in the [integrations-core repository](https://github.c
**Note for Chef Windows users**: as the datadog-agent binary available on the
node is used by this resource, the chef-client must have read access to the
`datadog.yaml` file.
+
+
+Development
+===========
+
+To contribute, you will have to follow the contribution guide in [CONTRIBUTING.md](./CONTRIBUTING.md).
+
+### Dependencies
+
+First, you should use [bundler](https://bundler.io) and the provided Gemfile to install the development and release dependencies.
+
+After having installed bundler, you can run the following command to install gem in a vendored folder:
+
+```bash
+bundle install --path .bundle
+```
+
+### Testing
+
+This project uses [rspec](https://rspec.info/) as its unit tests engine. It uses the related `chefspec` gem to abstract the chef logic. Some Chef specs can fail if you don't use the right version of Chef so be careful to use the one pinned in the Gemfile. To run unit tests, you can use:
+
+```bash
+bundle exec rspec
+```
+
+### Integration testing
+
+This project uses [kitchen](https://kitchen.ci/) as its integration tests engine. To really verify integration tests, you should have [vagrant](https://www.vagrantup.com/) installed on your machine.
+
+Kitchen allows you to test specific recipes described in [kitchen.yml](./kitchen.yml) across all platforms and versions that are also described in the same file. Each combination of recipe x platform x version is a test target.
+
+To list available targets, you can use the `list` command:
+
+```bash
+bundle exec kitchen list
+```
+
+To test a specific target, you can run:
+
+```bash
+bundle exec kitchen test <target>
+```
+
+So for example, if you want to test the CouchDB monitor on Ubuntu 16.04, you can run:
+
+```bash
+bundle exec kitchen test datadog-couchdb-ubuntu-1604-15
+```
+
+As there is a CouchDB recipe described in the `kitchen.yml`, and an Ubuntu platform with the 16.04 version.
+
+More information about kitchen on its [Getting Started](https://kitchen.ci/docs/getting-started/introduction/).
+
+### Development loop
+
+To develop some fixes or some features, the easiest way is to work on the platform and version of your choice, setting the machine up with the `create` command and applying the recipe with the `converge` command. If you want to explore the machine and try different things, you can also login into the machine with the `login` command.
+
+Please note that the `login` command only works on Linux & OSX and that you will have to connect to the VM through Virtual Box's interface on Windows. (Or via putty or similar ssh client)
+
+N.B.: The credentials of the created virtual machines are login `vagrant`, password `vagrant`.
+
+```bash
+# Create the relevant vagrant virtual machine
+bundle exec kitchen create datadog-couchdb-ubuntu-1604-15
+
+# Converge to test your recipe
+bundle exec kitchen converge datadog-couchdb-ubuntu-1604-15
+
+# Login to your machine to check stuff
+bundle exec kitchen login datadog-couchdb-ubuntu-1604-15
+
+# Verify the integration tests for your machine
+bundle exec kitchen verify datadog-couchdb-ubuntu-1604-15
+
+# Clean your machine
+bundle exec kitchen destroy datadog-couchdb-ubuntu-1604-15
+```
+
+It is advised that you work in TDD and that you write tests before making changes so that developing your feature or fix is just making tests pass.

Add development documentation