Bot releases are visible (Hide)
Published by cyberswat about 7 years ago
This is an interim release to address issue that have been discovered or resolved since https://github.com/drud/ddev/releases/tag/v0.9
Issues completed for this milestone include:
Published by rfay over 7 years ago
The intention of this milestone is to provide a functional provider plugin and pre/post hook functionality. Key aspects here include authentication, changes to app configuration files, storage of provider specific configuration, and the ability to import data (files and database) from one of multiple environments. Areas of focus include:
Issues completed for this milestone include:
Published by rfay over 7 years ago
The intention of this milestone is to address larger issues that require a bit of research, prototypes, and architecture in order to inform future decisions and features for the roadmap. Areas of focus include:
The key incompatibility introduced in this release is that mysql data store is now persistent (stored on the host/workstation instead of in the container). It's stored in ~/.ddev/<site_name>/mysql
. Databases can be removed with ddev remove --remove-data. The syntax of the ddev remove
was changed a bit as removing containers and a site no longer causes data loss.
Published by cyberswat over 7 years ago
The intention of this milestone is to clean-up important loose ends prior to an official release. Along the way, we have identified edge cases, bugs, ideas, etc. that we felt were important enough to capture but not distract from the focus of the earlier milestones. This is an opportunity to complete these items before our official 1.0. Summarizing our key areas of focus:
Recommend for each site:
ddev rm -y <everything>
rm -r .ddev
on each siterm -r ~/.ddev
docker rm -f $(docker ps -aq)
assuming you have only our containers - otherwise you will manually remove drud containers.Published by cyberswat over 7 years ago
Performance: one intention of this milestone is to ensure end-users have a positive experience with the overall real and perceived performance of ddev while performing typical day to day tasks. At a minimum, ddev's performance should be on par (or better) than alternative solutions. Out of the box, ddev's containers should be right-sized in terms of resources allocation and app/service configurations based on community accepted best practices. Performance should be testable (automated and manually) to ensure that as ddev's feature set increases that performance is not accidentally and unnecessarily sacrificed. Summarizing our key areas of focus:
The other intention of this milestone is to help meet a stated goal of "making the right decision the easiest." Security is often ignored or sacrificed to a competing need (speed, budget, functionality, etc), and we want to ensure that we are putting in proper safeguards by default. To that end, this milestone will focus auditing our current security practices and address issues that arise. Summarizing our key areas of focus:
You can get started easily by following the ddev installation instructions.
Issues completed for this milestone include:
#241 Security Audit & Recommendations
#283 Evaluate and (Potentially) Optimize the Drupal 8 GUI Site Install Time on macOS
#238 Create a basic performance test script for ddev
#256 Repeatable CMS page access performance benchmark tools dev environments
#253 Implement user-guided caching for web mount
#257 Performance: Repeat manual tests of ddev and related dev competitors
#195 Performance Testing, Management, Comparison (immediate and long-term techniques)
#131 Security: Files created by drupal in sites/default/files have root owner
#110 nginx-php-fpm container should not change permissions/ownership of mounted files
#258 Initial ddev windows performance review
#96 When a container has been removed, rewrite permissions back to user
#230 Upgrade repos for Drupal 7, Drupal 8, and WordPress
#129 Rework code to avoid shelling out to external commands
#70 Improve php.ini/mailhog configuration in nginx-php-fpm7-local container
#278 Consider ddev releases as part of the build process
Published by cyberswat over 7 years ago
The intention of thie v0.5 milestone (see roadmap) is to lay the foundation work necessary for end-users to achieve parity with external infrastructure (e.g. staging, QA, and/or production environments). Scope wise, this ability doesn't mean DRUD Tech is looking to maintain responsibility for maintaining container definitions for every possible hosting provider. This is more of a working proof of concept with documentation for end-users to extend to meet their specific requirements. Key areas of focus for this milestone are as follows:
In addition to this, we prioritized an optimization regarding the following:
Issues completed for this milestone include:
#121 As a developer, I want the ability to use custom containers.
#164 Adjust ddev describe
output for exited projects.
#240 Split v0.6 Milestone Into More Manageable Pieces
#212 Update readme to include a link to the roadmap and a stronger introduction.
Published by cyberswat over 7 years ago
This release experimentally introduces windows support.
#196 Decisions and Plan for Linux & Windows Support
#99 As an end-user, I want notifications and instructions regarding upgrades.
#40 Stop/remove the nginx-proxy container if no sites are up
#98 As an end-user, I want a way to quickly install ddev via a script
#136 ddev project name uniqueness should be enforced
#153 Improve ddev list
command
Published by cyberswat over 7 years ago
Ddev now has an install script available.
#108 Provide a wp-cli command hint to adjust WP production URL
#81 Hide (gray out) "sequelpro" command when it is not available in path
#87 ddev logs to provide only nginx error logs; instructions for advanced users on other logs
#117 Security: ddev can be used to sudo an arbitrary command
#93 As a community, I want a roadmap
#139 Make name, dba, dbimage and webimage optional in config.yaml
#91 As a developer, I want the ability to use phpMyAdmin
#90 As a PHP developer, I want to be able to use Composer
#130 Respect settings.php where it exists (if ddev didn't create it)
#88 As a developer, I want XDebug step-debugging support for IDEs like PHPStorm
#89 Finish MailHog integration
Published by cyberswat over 7 years ago
Published by rfay over 7 years ago