Despite the title here, I actually 'released' cdev to the world back in 2017. I had been building it in my own time as a way of making development environments consistent across my team, I wanted devs to be able to start on a project with a simple 3 step process:
Too often I've seen repositories with no readme, no instructions on how to get started and where to get your config & backups from. If a team member needs to take hours to get their environment setup it can eat up time - particularly problematic for smaller projects where those hours are a significant part of the budget.
Without this setup it often leads to situations where projects 'belong' to particular members of the team, who then become a font of all knowledge for the project (which in itself is not a bad thing) but if there's no prospect of anyone else working on it they often (always) fail to share any of that knowledge with others, God forbid they should ever go on holiday, or leave...
Backups play a role in 2 of the 3 step process above, we'll skip over pulling the backups for now and talk about 'start site'.
When you're firing up your dev environment you (probably, framework dependant) want to import your database too. To keep this nice and consistent we have a 'db' folder in the project root that cdev imports files from as the environment boots up. This isn't strictly enforced, other environment plugins can choose to load db files from elsewhere, but keeping it consistent (notice how I talk about consistency a lot?) means that you can reconfigure to use a different environment without having to move the rest of your files around.
To get the files into that db folder there's a cdev helper function `cdev backup:pull` you can specify whether you want the db, the media or everything and it will download them. There are 2 storage locations configured, either a server or an S3 bucket. At Creode we use S3 buckets, each developer has their own individual keys that grant access to the buckets they need, meaning they can pull in project backups without needing to enter any further credentials (exception for password protected keys).
I introduced a beta version of cdev to my team once I had it running. The core ran docker containers for php/apache/mysql/mailcatcher (mailcatcher is ace btw, it stops dev/test environments sending out emails, potentially to clients, and gives you a web interface to look at what would have sent) and supported our core frameworks, wordpress, drupal, magento (at the time). I've since refactored this so that the environment types and frameworks sit in their own plugins, more about that later.
I've talked about cdev at a couple of meetups here in Leeds, the first an impromptu explanation of what it does and how it came about with zero prep time (there was no talk lined up, and the floor was opened to the room for show and tell) and gained a couple of fans.
Plugins were introduced to allow developers to create their own tools & commands to run via cdev. Particularly of interest were the environments and frameworks that it supports.
Initially cdev was a docker only tool, but as a mac-based team we often found speed issues (there are well documented NFS issues on docker for mac) made development painful. My colleague Jamie released a cdev local environment plugin a few months ago, using brew services and some clever apache config to run a variety of PHP versions across multiple sites.
There is of course the option to contribute, so if you'd like to see any other environment types (vagrant has been mooted, as a member of the team is keen on it) then feel free to build plugins and let me know about them.
The idea of a framework plugin is that you can run a single generic command to clear caches (amongst other things) across all frameworks, rather than remembering `drush cc` or `bin/magento cache:flush` you just run `cdev cc` and it'll run the appropriate command for you.
If you've got any questions about cdev, feel free to ask via github, you can find the repo here
