Ddev: v0.19.0 Release Checklist Due 2018-05-29

Created on 22 May 2018  路  19Comments  路  Source: drud/ddev

Remaining actions:

  • [x] Review release (product owner)
  • [x] Approve release (product owner and release manager)
  • [x] Create binaries (any DRUD maintainer)
  • [x] Draft release notes (release manager)
  • [x] Draft additional announcements for blog, newsletter, etc (not applicable at the moment)
  • [x] Create release (release manager)
  • [x] Update Roadmap (TPM/release manager)
  • [x] Followup issues spun off if we need them.

For additional background information, please see our Product Release instructions here.

Most helpful comment

Ok... I'm happy with how this turned out. I'm still not happy that I'm not able/willing to give Windows 10 the attention it needs, but I may need to rely more on @andrewfrench in the future to confirm parity when @rfay gets a Windows specific fix in (and vice versa when @andrewfrench submits a PR).

Ready for getting this together as a release. Thanks, everyone!

All 19 comments

Updated issue summary to reflect roadmap updates as part of release checklist.

Here is my working copy so far.

ddev v0.19.0 Review

Executive Summary

Based on the following analysis, ddev v0.19.0 is not ready for release.

Milestone Overview (CMS Specific Functionality)

TODO

  • UX/DX:
  • Documentation:
  • Security:

Additionally, there are...

Testing

Performed by Rick Manelius as of 2018-05-29

Hardware Setup

I鈥檓 using a laptop with the following high-level specifications:

  • MacBook Pro: Retina 15-inch Mid 2015
  • 2.2 Ghz Intel Core i7
  • 16 GB 1600 MHz DDR3 RAM
  • 250 GB Hard Drive
  • macOS Sierra 10.12.4

Software Setup

  • Xcode
  • Docker 18.03.1-ce
  • Git 2.15.1

Repositories Used

Preparation

  • ddev

    • git checkout d4c4590f

    • make clean && make darwin

    • ddev version => v0.18.0-20-gd4c4590f

Results

Working

Needs Work

Decisions

Based on the following analysis, ddev v0.19.0 is not ready for release.

Recommendations

  • TODO

Found a few things in my initial issue scan that could be updated/improved.

I'm intending to test the following for the release. @rfay, if you have any additional items to callout and test more explicitly, let me know. I'm focusing on end-user changes and new features vs bug fixes, but if there are ones that I should draw more attention to...

Milestone Overview (Reducing WIP and UX/DX Improvements)

There is a significant amount of work being done under the hood in this release in preparation of getting back onto a more formal roadmap schedule (see updates here https://github.com/drud/ddev/wiki/Roadmap). Still, there were several user experience features worth calling out.

In addition there were a considerable amount of bug fixes and optimizations (see https://github.com/drud/ddev/compare/v0.18.0...e5d9c86020). We've addressed regressions on Linux support, moved the docker image definitions into the repo, and performed upgrades to our testing infrastructure.

@rickmanelius I reviewed the list you put there and think it's good. I was quite surprised how many commits/PRs we have in this release. I think people would just choke on the info if we tried to describe every fixed bug.

@rickmanelius Please test against current master: https://github.com/drud/ddev/commit/4ddabc7c15620842e185476b6dfc15e944e58479, which hopefully will be the hash we tag as v0.19.0

@rfay Yup I checked out that exact commit, so I'm all set there.

BTW, I'm now done testing 3 of 5. I think I have found a regression for the multiple hostname validation. I'm posting it here in case this is how it was intended to work.

  • DX: Fix issues with duplicated hostnames

    • Stock Drupal 7.59 site with default answers to ddev config

    • I open and modify config.yml to specify non-default ports

    • Complete a basic site install w/standard profile.

    • Edited .ddev/config.yml and viewed the blank entry for hostnames and the instructions below.

    • See recommendations. The instructions on how to do this should probably be consistent with the stubbed out entry.

    • I modified this to read additional_hostnames: [site1, site2]

    • I re-ran ddev start

    • I was prompted to get /etc/host modified.

    • I see output for HTTP/HTTPS versions of all 3 hostnames

    • The site is now accessible through all 3 sites (primary as project name and site1 and site 2)

    • I create a new, blank site called "site1" and attempt to run ddev start

    • This takes a significant amount of time (30s?) before it times out.

    • The router times out and leave it in an unhealty state.

    • If I remove the conflict site with ddev rm, the other sites are now available again.

    • I'm not sure this was fully working in https://github.com/drud/ddev/pull/825.

  • The conflicting hostname fix did not address identical hostnames across different projects. Only within a project.
  • The conflicting project name regression should have been fixed.

But that never meant that we solved the possibility of having two projects fighting each other for additional_hostnames. I think this is mentioned in the additional hostname uniqueness issue.

Edit: See https://github.com/drud/ddev/pull/825 "This PR does not solve the problem of multiple projects competing for one hostname."

@rfay Excellent. Thanks for the insight on that. I'll move that to a recommendation then and test conflict just within a project.

ddev v0.19.0 Review

Executive Summary

Based on the following analysis, ddev v0.19.0 is ready for release.

Milestone Overview (Reducing WIP and UX/DX Improvements)

There is a significant amount of work being done under the hood in this release in preparation of getting back onto a more formal roadmap schedule (see updates here https://github.com/drud/ddev/wiki/Roadmap). Still, there were several user experience features worth calling out.

In addition there were a considerable amount of bug fixes and optimizations (see https://github.com/drud/ddev/compare/v0.18.0...e5d9c86020). We've addressed regressions on Linux support, moved the docker image definitions into the repo, and performed upgrades to our testing infrastructure.

Testing

Performed by Rick Manelius as of 2018-05-30

Hardware Setup

I鈥檓 using a laptop with the following high-level specifications:

  • MacBook Pro: Retina 15-inch Mid 2015
  • 2.2 Ghz Intel Core i7
  • 16 GB 1600 MHz DDR3 RAM
  • 250 GB Hard Drive
  • macOS Sierra 10.12.4

Software Setup

  • Xcode
  • Docker 18.03.1-ce
  • Git 2.15.1

Repositories Used

Preparation

  • ddev

    • git checkout 4ddabc7c

    • make clean && make darwin

    • ddev version => v0.18.0-26-g4ddabc7c

Results

Working

  • DX: "ddev describe" should show direct ephemeral port/url via localhost

    • Stock Drupal-7.59 w/default ddev config

    • Verified new db, web, dba, and router images pulled tagged with v0.19.0

    • When ddev start finished, I observe 3 URLs posted: http://PROJECTNAME.ddev.local, http://PROJECTNAME.ddev.local, and http://127.0.0.1:RANDOMPORT

    • Running a Drupal site install against one and attempting to resolve both HTTP URLs resolves to the same site.

    • I ran docker ps -a and located the PROJECTNAME nginx container and confirmed the portnumber routes to the HTTP port.

    • I modified .ddev/config.yml to include non-standard ports for HTTP/HTTPS and verified this continues to work.

    • I note that ddev list doesn't show the 3rd URL without the project name. That's fine.

    • ddev describe -j shows the http://127.0.0.1:RANDOMPORT value in the "urls" key.

    • CONFIRMED

  • DX: Add .mysql to allowable database extensions for import.

    • Stock Drupal 7.59 site with default configurations.

    • ddev ssh and drush dl backup_migrate and drush en backup_migrate

    • Visit http://drupal-7.59.ddev.local:81/admin/config/system/backup_migrate and submit the "Backup Now" button.

    • Verified a drupal-7.59.ddev.local-2018-05-30T20-00-39.mysql.gz download

    • exit container and run ddev rm --remove-data then ddev start

    • Verify no database exists when attempting to reach http://drupal-7.59.ddev.local:81

    • run ddev import-db --src=~/Downloads/drupal-7.59.ddev.local-2018-05-30T20-00-39.mysql.gz

    • FAILED. We still have an issue where our nginx container will not properly export gzip.

    • Renamed the exported db to remove the faulty .gz extension, run gzip

    • Re-run ddev import-db with the corrected file and it imports!

    • CONFIRMED

  • DX: Allow environment variables to propogate into php-fpm
  • DX: Fix issues with duplicated hostnames

    • Stock Drupal 7.59 site with default answers to ddev config

    • I open and modify config.yml to specify non-default ports

    • Complete a basic site install w/standard profile.

    • Edited .ddev/config.yml and viewed the blank entry for hostnames and the instructions below.

    • See recommendations. The instructions on how to do this should probably be consistent with the stubbed out entry.

    • I modified this to read additional_hostnames: [site1, site2]

    • I re-ran ddev start

    • I was prompted to get /etc/host modified.

    • I see output for HTTP/HTTPS versions of all 3 hostnames

    • The site is now accessible through all 3 sites (primary as project name and site1 and site 2)

    • I then add another entry of "drupal-7.59" which matches the projectname of "drupal-7.59"

    • ddev start

    • I confirmed that it ignored the duplicate entry.

    • CONFIRMED

Not Retested

  • UX: Adding Support for Windows 10 Home

    • I still need to familiarize myself more with Windows 10 and 10 Pro in a way that is efficient enough for me to perform these tests without holding up the release. To that end, if we've confirmed the Docker Toolbox install, we should get on stack overflow

Decisions

Based on the following analysis, ddev v0.19.0 is ready for release.

Recommendations

  • HTTPS on 127.0.0.1: I still would like to see HTTPS on the direct localhost:RANDOMPORT webhead connection. It's not mandatory for this release.
  • Backup Migrate gzip compression library. We should get this installed on the nginx container.
  • Multiple Hostnames. While this is a nitpick, not everyone understands the multiple ways of inputting .yaml. The uncommented entry is "additional_hostnames: []" whereas the instructions use the syntax of newlines prefaced by a "-". It might be worth making those consistent. Also, we are not validating if other hostnames are actively being used, so it's possible to collide and put the router in an unhealthy status.

Ok... I'm happy with how this turned out. I'm still not happy that I'm not able/willing to give Windows 10 the attention it needs, but I may need to rely more on @andrewfrench in the future to confirm parity when @rfay gets a Windows specific fix in (and vice versa when @andrewfrench submits a PR).

Ready for getting this together as a release. Thanks, everyone!

Yay! @andrewfrench and I will schedule time today to go through the release process and document it in docs/developer.

@rickmanelius responses to your Recommendations:

HTTPS on 127.0.0.1: I still would like to see HTTPS on the direct localhost:RANDOMPORT webhead connection

If you'd like HTTPS on the web container port, it would mean duplicating the cert generation features in the web container or possibly changing the architecture to terminate HTTPS on the web container. It would also mean turning on a separate port for nginx, and exposing 2 different ports from the web container. It's not a small rock, and I'm not sure how it fits architecturally.

Backup Migrate gzip compression library. We should get this installed on the nginx container

I didn't understand this statement. I assume you might be referring to the backup_migrate bug in https://www.drupal.org/project/backup_migrate/issues/2926610, which we don't have any control of. Anyway, when you do a direct download of a backup_migrate db, it doesn't get gzipped.

Multiple Hostnames. While this is a nitpick, not everyone understands the multiple ways of inputting .yaml. The uncommented entry is "additional_hostnames: []" whereas the instructions use the syntax of newlines prefaced by a "-". It might be worth making those consistent

I agree with your concern on that. The reason that the default is the [] array syntax is that's what golang outputs for an empty yaml array. The bulleted yaml approach used in the docs/examples there is easier to read and easier to use. Both work. I don't know any reasonable way to get the golang yaml to output the bulleted version, so we could change the doc to use the array syntax if that's important.

we are not validating if other hostnames are actively being used, so it's possible to collide and put the router in an unhealthy status.

I think we should probably figure out how to solve this one in Make ddev-router more transparent about failures. I added a note about this case in that issue.

Removing this from the v.19 milestone as we close out that release using this checklist.

Release generated. Blog articles and newsletter shipped. Last step on @dclear to update the roadmap to reflect the completed milestone and we can close this out.

I edited the op with a checkbox for "Followup issues spun off if we need them."

Closing, as I believe this is done.

Was this page helpful?
0 / 5 - 0 ratings