Features

Ephemeral Environments And The Ideal Dev Workflow

For development teams to be successful, they need to have a well-defined developer workflow. This starts where engineers work and iterate on features on a branch, also known as the development environment or developer workspace.

Developer workspaces (local or remote)

Developer workspaces are often local, such as an engineer’s laptop. Remote workspaces are becoming increasingly popular as more IDEs (such as VS Code and IntelliJ IDEA) support remote development.

In many organizations, setting up the developer workspace is a manual process. This is often the root cause of “it works on my machine” bugs, and causes failures upstream.

Ephemeral developer workspaces:

Automate setup steps (e.g clone repository, install IntelliJ, OpenJDK 11, Gradle) for engineers onboarding or recreating their workspace
Source-control the dependencies for engineers' development workspaces
bonus: Dependencies maintain parity to the production/staging environments

Development teams can use local tools (docker, tilt, vagrant) and even remote platforms (Github Codespaces, GitPod, Coder) to manage ephemeral developer workspaces.

Committing, Pushing, and PRs

developers organize and document their changes and additions in commits
when ready, they will open a PR for code review to merge the changes from their branch

Code Review

an ephemeral staging environment is created upon the prior PR being opened
a series of automated tests will be run against the new environment to test new features and look for regressions
developers will start code review by accessing the ephemeral environment and interacting with new features
they will also look at code itself, and may request changes
the owner of the feature is now responsible for resolving and updating any issues found through this process
upon updates to PR, the environment rebuilds automatically for code review

QA Process

after the code review is complete, QA teams receive a link to the new corresponding ephemeral environment
they will review and test any changes and new features
if there are no regressions and each feature is up to spec, QA is complete

Ready for Merge

if all steps are successful, the changes will be merged to production and deployed
any remaining staging environments can now be spun down