Development Lifecycle

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 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 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.