-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explore Lagoon Developer Experience #12009
Comments
Repointed during discovery & after acceptance criteria modifications. Good per Dotti |
Shifting to Sprint 75 due to holiday scheduling conflicts. |
@ElijahLynn has this been completed? If not, I'll bring into sprint 76 |
No, this got derailed before our onsite and with the team structure shift. |
Notes on working with Pygmy while Lagoonizing CMS-Test
Googling around landed on Amazee docs. Had a thought to try and manually start haproxy.
Sucess!
Ran |
Lagoon support for DDev rough notes: |
@ElijahLynn @olivereri where are you at on this one? |
Not much more progress than what is documented above. I feel like this one is blocked by #12291 because we need a working PoC to really work through DevEx. |
@olivereri @ElijahLynn just checking in on this one to see if it is still blocked and if we anticipate this being completed by the end of sprint 77. Thanks! |
Sorry @ElijahLynn this was confusing. We just explained to Dave that this was blocked by what we are working on now. It should have never been prioritized before the demo environment to begin with. He's fine with it. Don't worry about this one. Just focus on #12291 for this sprint |
Okay, thanks. |
Initial Assumption: There should be no change to Drupal Engineer/Developer experience (DevEx). Reasoning: Tighter DDEV and Lagoon integration is a nice to have, not a technical blocker. Developers can still use DDEV for local development, create PRs, and merge them even if Lagoon is our new hosting platform. By not using Pygmy, Lagoon's preferred local development option, developers won't be testing locally a mirror of Prod. Impetus: The "nice to have" portion is a desire to use a single container image as a source of truth. Not having multiple container configurations that must be tracked and accounted for when, for example, upgrading PHP versions. With the adoption of Lagoon there were will be three (3) configurations to track: Tugboat, Pygmy, DDEV. |
IntroductionThe initial assumption is correct. This will have no impact for CMS Engineers on WIndows, Linux, or Mac (Intel and M1), unless we want it to. The Usage of Lagoon does not obviate the use of existing local development tools, i.e. DDEV. It is actually preferable to continue using DDEV for local development rather than Lagoon's preferred tool for local development, What is Pygmy?Pygmy is a Docker based Drupal Development environment that simplifies local development environments for web applications. Lagoon, on the other hand, is a container-based hosting platform for web applications. While they are both used in the context of web development, they serve different purposes. That being said, Pygmy can be used in conjunction with Lagoon to provide a local development environment that closely matches the production environment in Lagoon. This can help to minimize differences between the local and production environments and ensure that the application works as expected when deployed to Lagoon. To use Pygmy with Lagoon, you can follow these general steps:
Pygmy provides several things that Docker does not:
Advantages of DDEV over PygmyDDEV provides several features that Pygmy does not have, which can be useful for Drupal development. Here are some examples:
Overall, while Pygmy is a powerful tool for creating Docker-based local development environments, DDEV offers a more comprehensive set of features that make it a better fit for many Drupal development projects. Developers working on Drupal projects may find that the Drupal-specific integration, Xdebug support, and comprehensive CLI tools of DDEV make it the better choice for their needs. Other Areas of Developer ExperienceUsing Lagoon to deploy and host the CMS may have a few more developer experience advantages over the current hosting system. Currently Jenkins is used as the deployment orchestration tool to run all jobs or tasks required to deploy and generally run the CMS. Finding what job runs deploys, builds and run-time tasks can be daunting. Jenkins is shared with other projects and the UI can get very noisy. It also is an issue inspecting the code for the jobs and Ansible playbooks since they exist in a separate repository. With Lagoon this will be all more centralized for the UI and codebase. It will become far easier for developers to track their changes from Pull-request to deployment than it currently is. Improvements and Changes for LagoonCurrently we are recommending a partnership between Lagoon and DDEV to provide closer integration for local development. This would be like the support that Lando already has for Lagoon:
With that integration it would be possible for DDEV to be more representative locally of what will run on production while taking advantage of all the development features DDEV provides. Additionally, it would result in less work for DevOps engineers to maintain separate PHP configurations for each environment and carefully keep thme in sync. With regard to the Lagoon UI some developer experience imporvments are:
|
Overview
Lagoon is a powerful devops tool that will greatly streamline developer interaction with the CMS. In order to make the most of this tool and streamline our development process, it is important that we have a clear understanding of how to set up and use Lagoon for local development.
As a CMS engineer, I need a clear understanding of how my changes go from my local machine, through approval, and to the production website. How will implementing Lagoon impact my current workflows and what do I need to do in order incorporate those changes?
tl;dr: Change Management for local development
Proposed Tasks
Why this Matters
By documenting and exploring the Lagoon local dev setup, we can better understand its capabilities and limitations and make informed decisions about how to incorporate it into our development process. This will help us streamline our workflows and improve the efficiency of our development teams.
Acceptance Criteria
Feedback from external teams sought in Sprint 75.
The text was updated successfully, but these errors were encountered: