As the head of development, it’s my job to be sure that our developers are developing, that they can come in and get their work done efficiently, with high quality, and as little friction as possible. This involves input, output and all that’s in-between.
What’s the input? High fidelity, clear, functional and technical specifications are key.
Output: High quality delivery to QA. the deployment CI/CD workflow., the hosting and services around that which define the platform.
Today I’m going to talk about one of the in-betweens, local development.
My History with Local Development
A little over 20 years ago I made a big change in my career. 9/11 just happened, my now spouse was living in Paris, and I was still coding in PERL. PHP was emerging as the dominant scripting language for content management systems on the web. So I did what any sensible young person would do, I quit my job and hopped on a plane to France!
But not before buying a PowerBook.
The PowerBook was a breakthrough. OSX is a flavor of BSD and it came with the Apache web server and MySQL preinstalled. All I had to do was get PHP on the box and I was set to hit the learning curve. And while all this was a breakthrough at the time, I was still required to learn quite a bit about operations; namely setting up and maintaining a web stack on my laptop. It was a means to an end and never the objective, I wanted to be a software developer, not a systems administrator.
It went like this for years. Eventually MAMP came along and that made things easier. And then there was Kalabox that morphed into Lando which managed to reduce the time I spent time managing my local development environment and increased my productivity all with one install. Lando boasts tight integration with hosting platforms like Pantheon which we’ve been using for years here at Capellic.
While great, this still requires software developers to sit in the systems administrator seat to install, configure, upgrade, and troubleshoot when things go wrong. And then these tasks are made harder if you’re on a Mac due to very well documented performance issue. It’s all starting to add up — the time away from being a software developer, the loss of productivity, the gear grinding, the frustration.
There’s got to be a better way.
Introducing Cloud Development Environments
About a year ago we caught wind of a potential solution: Cloud Development Environments, or CDEs.
A CDE is a local environment but in the cloud. There is nothing installed on the developer’s machine but a web browser through which the CDE is accessed (and possibly an IDE client). It provides all the capabilities a software developer needs: a server, database, PHP, (anything that can be installed into a Docker container) and a choice of code editor such as VS Code or phpStorm. It can be used on any computer — Windows, Linux, OSX, etc.. Local development environments require a lot of computing power, but with a CDE that’s all done on a remote server and so the developer’s machine need not be the latest or greatest and this allows us to extend the life of our fleet of laptops.
And it does it all with a click of a button. A developer can now create a branch and launch a workspace from a Jira ticket. Within minutes they’re able to get to work. A cloud-based development environment also means they can be actively working on multiple tickets in multiple workspaces with unique database states, a workflow that is tedious on a local development environment.
So who’s talking about it? Who’s doing it?
Check out these articles: Finally, Software Creation Joins The Cloud, Software engineers spend lots of time not building software, Works on my Machine, Cloud Development Environments Tame Complexity By Reducing State, The future of writing software happens in Cloud Development Environments (CDEs), I said goodbye to local development and so can you.
And there are some large software development operations looking to the cloud as a solution to the inefficiencies I’ve articulated above: Shopify, MongoDB, Stripe, Airbnb.
I’m not going to hold back, I’m pretty excited when I think of the possibilities: Get the operations out of the way so our developers can get to developing and providing value to our clients.
Exploring Gitpod with DDEV
Okay, so far so good, but how do we get there? What CDE do we like, Gitpod or Codespaces or other? How does it work with our other tools and flows? Is it performant? How easy is it to administer? How much does it cost?
At this point in the process we’re testing Gitpod with DDEV. We have established a common configuration for the sites we manage which includes Drupal plus Storybook or PatternLab. More and more we’re processing tickets and building features in Gitpod and we’re noting the pros and the cons. It’s too soon to come to any firm conclusions. We want to get beyond the phase of “rose colored glasses” and see how this stands up over the long haul.
Here’s a tutorial of how we’ve configured Gitpod and DDEV to do our Drupal development.
