We are not sure what people calls it or if it formally exists. We call it Documentation Driven Development (DDD).
Under Documentation Driven Development, this is how we do things:
- We pick a task/feature.
- We then evaluate the need for it, identify existing solution, spend days reading and getting hands on it.
- If we see value in it, we start documenting the way we are using it – mostly in an internal Google Doc.
- Then we test new methods/process on our test servers, from there on our production servers.
- As we move from one round of testing to the next one, we keep updating the document.
- Finally, we post document under https://easyengine.io/tutorials/. You may visit Composer & WordPress section for a currently work-in-progress section.
- Here is the point where people who read our articles gives us feedback.
- Assuming, the documented thing is ready for easyengine integration, we create a “draft” documentation page about CLI interface i.e. commands, subcommands, arguments, options and their default/possible values under https://easyengine.io/docs/commands/. We add a note to the page, so the user understands that the document refers to the future commands. There is no example of any “draft” document page publicly accessible.
- When a new version of EasyEngine is ready, we verify it against the document. If there is a mismatch, we discuss it and either fix code or docs or both.
- Release new version.
- Test new version on our clients’ test server and production server, in this order only.
