BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Cloud Based Development - from Dream to Reality

Cloud Based Development - from Dream to Reality

Leia em Português

Bookmarks

Key Takeaways

  • Setting up and maintaining consistent development environments adds no business value at all. It can be a time-consuming, often mundane task, one that developers should not have to worry about.
  • Individuals and businesses leverage cloud platforms and SaaS offerings for the majority of their software development lifecycle, except for "Development / Implementation / Coding".
  • Eclipse Theia is an extensible platform to develop multi-language Cloud & Desktop IDEs used by Google, Eclipse Che and Gitpod to provide cloud-based development environments.
  • Imagine that getting started with a project was as simple as opening a URL in your browser - exactly this is no longer a dream, it has become reality.
     

I have spent close to two years developing software on a Chromebook. 16GB RAM, a 512GB solid state drive, ChromeOS, a wide screen monitor and an internet connection. It has been the most productive time of my career. Let me take you on a journey, from the days when computers were terminals to access compute power on shared servers, to times when compute power moved to desktop / laptops, all the way (back ?) to my current workflow where laptops are a thin layer to interface with compute power on shared servers again - a.k.a in the cloud.

Paper, whiteboards, in-person meetings & in-house servers

A representation of the software development lifecycle (SDLC) contains the following five stages:

5-Stage SDLC

In the early days, we gathered requirements in person and on paper. We designed on whiteboards. We developed and tested source code on desktop computers and deployed to in-house servers where we operated and maintained applications. What sounds like ancient times really was a mere two decades ago in my case - for others a lot of that still applies today.

We performed the SDLC stages offline and on-premise. The most "modern" step was arguably "Implementation", where developers used their computers as terminals to access early versions of the World Wide Web, helping them to find answers to problems, write software or participate in IRC channels with like-minded individuals.

Implementation - The Getting Started Challenge

As part of the implementation stage, each developer follows (documented) instructions to set up their personal development environment. These instructions look something like this:

  1. Install editor X, add plugins Y and Z
  2. Download the source code
  3. Install required language SDKs and dependencies
  4. Compile & run software locally

Software development is a dynamic profession, source code changes daily and once in a while, so does the way the local development environment needs to be set up.

For existing team members, development environment changes are incremental. Install a new plugin, upgrade to the latest version of a dependency or execute a temporary script. If your experience is anything like mine, the internal "Day 1: Development Setup" wiki page tends to be forgotten which, so it seems, is fine as it doesn't impact anyone. The incremental change is communicated ad-hoc during a daily standup or over an instant messaging platform.

Then there's Hanna. She has recently accepted to join the team and is excited for her first day and eager to get up and running quickly. She opens the Day 1: Development Setup wiki page, follows along, being grateful the team documented these steps. Except, step 8… it doesn't work. A team member helps her out, they fix it and move on. The pattern repeats throughout the remaining process. Time passes and the first day ends with less excitement than it began with...

To the cloud we migrate

Thanks to the internet, software as a service solutions quickly brought a significant shift to a software team's daily routine. What used to be done manually and offline can now be performed more efficiently online, with real-time collaboration and quick, in-the-moment feedback loops.

Nowadays, it is common for the requirements, design, test and maintenance stages of the SDLC to be performed in the cloud. Whether a business migrates to the cloud or is born in the cloud, a so-called cloud-native business, the trend is crystal clear: The cloud is here to stay and the SDLC too adopts this innovation. Except for the Implementation stage...

What happened to "Implementation"?

Let's look at the SDLC again. This time, we highlight which stages are performed in the cloud and which are not (yet).

For all stages but Implementation, we use a browser as the terminal to access software in the cloud. What once used to be the stage where we were quite ahead of the curve has been left behind while all other stages have innovated and continue to do so. Development teams across the globe to this day use powerful, often expensive hardware to write & compile source code, only to immediately push it to the cloud. Not to mention the need to upgrade that hardware every few years.

With cloud computing at the forefront of so many industries, processes and our daily life, it is time to ask an important question:

What happened to the Implementation stage?

Two related, equally important questions to ask ourselves are:

  • Why do we still require high-spec laptops to write software?
  • What makes it so difficult to move this stage to the cloud?

First and foremost, the reason for the Implementation stage to be such a laggard is due to a lack of available solutions that are easily adoptable. Solutions such as Cloud9, code-server and possibly others exist, but do not seem widely used.

Meet Eclipse Theia & Gitpod

At long last, with Eclipse Theia we have an open source "platform to develop multi-language Cloud & Desktop IDEs with state-of-the-art web technologies". Theia is already used by Google Cloud, Eclipse Che and Gitpod.

I want to focus on Gitpod as a hosted-service. It allowed me to completely transform the way I develop software. As a Chromebook user, the majority of my daily tasks already happen in the cloud and for a while I have dreamed of a day when I no longer need locally installed applications at all! While Chromebooks support Linux applications and allowed me to use VS Code, up until a few months ago it still required me to install and maintain software locally.

With Gitpod in mind, let me rewrite your Your Day 1: Development Setup wiki page:

First & final step: Open gitpod.io/#https://github.com/your-org/your-repository

In fact, remove the wiki page and add that link to the project's README.md file instead - keep documentation close to your source code.

A click on that link is all it takes to start the development workspace. Remember Hanna from earlier? Her onboarding experience is now joyful and truly exciting. New team members are ready to contribute within minutes, not days!

With the .gitpod.yml configuration file placed at the root of your project, you get access to a wide range of additional features described below.

Consistency with Docker images

If your project requires any 3rd party tools or other customizations, you can provide a custom Docker image. Once configured for a project, each new workspace is based on that image and all changes to that image are applied the next time a team member opens the workspace. As an added benefit, all changes to this Docker image become part of your version control history. No more uncertainty of what changed when by whom.

Prebuilt Workspaces

Imagine your colleague assigns you as the reviewer of a pull request. With prebuilds enabled, Gitpod automatically prepares the workspace (download the PR's code, install dependencies) so that by the time you open the pull request workspace, it's ready to review and test.

Built-in code reviews

Have you ever looked at a pull request, said to yourself "This looks good" and left a LGTM comment, without actually testing the code? Right, you have - we all have. Gitpod comes with a built-in code review feature that lets you review changes and leave comments inline. For even better productivity, you can configure Gitpod to add a PR comment with a link to a workspace that contains this exact pull request's code changes.
Your workflow as a reviewer now is: Open PR; click link; review & test code.

Parallel & Shared Workspaces

A personal favorite, parallel workspaces allow me to review code without interrupting my own development changes. No more commit messages like "WIP: Temporary commit." or stashing to change a branch for a pair programming session with my team member. Simply open a new workshop in a different browser tab, share the workspace with the team member and pair program - even remotely. When you're done, close the browser tab and you're back in your own workspace with your work.

Support for VS Code extensions

Lastly, for any VS Code users, you can install your favorite extensions and they are automatically applied to all workspaces you work on. It no longer matters whether you work on your laptop or anywhere else, your extensions are available as soon as you login to Gitpod with your account.

Do you recommend all team members to use certain extensions to make them more productive? Configure these extensions at a project level and anyone who works on that project has the extensions available automatically.

How to get started

All that is required is a repository URL. To get that, please create a new repository on either GitHub or GitLab and make sure you initialize the repository with a README. Alternatively, feel free to use an existing repository!

To start up the Gitpod environment for the new repository:

  1. Copy the repository URL.
    • You can use this URL if you do not have a URL available.
  2. Open a new browser tab.
  3. Type "gitpod.io/#" in the URL field and append "https://your-repository-url".
  4. Click Login with GitHub & Launch Workspace.
  5. When prompted, authorize Gitpod to access your GitHub or GitLab account.
    • No need for a new username & password on Gitpod.
  6. Accept the Gitpod terms of service and click Create Free Account.

Within a few seconds, your Gitpod environment is up and running.

Gitpod project setup

A notification offers to set up the Gitpod configuration.

Click Setup Project. This slides in a setup wizard that guides you through the process.

Step 1: Create .gitpod.yml

Click Create .gitpod.yml to set up a basic configuration file.

Step 2: Change Base Image

This is where you can select a different base image, e.g. with MySQL installed. Alternatively, you can choose a custom image, specifically to the needs of your business and project.

Step 3: Update Readme

Click Update Readme to add a Gitpod badge. With that, anyone who works on the project can start the Gitpod environment with a single click on the badge.

Step 4: Test Drive Configuration

Note: If you used my sample repository URL, you're asked to fork the project at this time because you are not a collaborator. If you use a project you own, you can push without the need to fork.

Click Push to Branch & Start Workspace. In order to push the branch, Gitpod asks for permissions. Click Grant Permissions and in the new window, click Authorize gitpod-io. Click OK to close the Permissions updated dialog, then close the browser tab.

Follow the instructions to push the code changes and track the branch as an upstream branch.

Step 5: Create a Pull-Request

In this final step, Gitpod provides an interface to create a new pull request that contains the Gitpod configuration. Click Create pull request to open the PR.

To see what the most basic configuration looks like, have a look here.

Code Review

Once the pull request is open, your team member can review it:

  1. Navigate to the pull request in your browser.
  2. Copy the pull request URL.
  3. Type "gitpod.io/#" in the URL field and append "https://your-pull-request-url".
    1. E.g. gitpod.io/#https://github.com/mikenikles/gitpod-getting-started/pull/1

Shortly after that, Gitpod is up and running with the code from that pull request, ready to be reviewed, tested and merged.

The reviewer can leave comments right from within the development environment:

Cloud based development going forward

Once the Gitpod configuration pull request is merged, anyone who works on the project can click the Gitpod - Ready-to-code badge on the project's README and start developing a few seconds later.

Conclusion

Eclipse Theia recently released version 1.0 of its Cloud & Desktop IDE Platform. It marks a major shift in what I see as the last remaining stage of the software development lifecycle to fully migrate to the cloud - the Implementation stage.

I expect the work-from-home culture to become more important to businesses around the world as they look to onboard the best talent, a talent that does not necessarily live near their offices. With Eclipse Theia and a hosted version of it on Gitpod.io, we are a big step closer to a complete end-to-end development experience in the cloud.

Now that the getting started process is as concise as a single click, you can think about the next step in efficiency: What is left to improve in your project so that new team members can release their first contribution to production by the time they go home at the end of their first day at work?

About the author

Mike Nikles is a software architect who values productivity & team morale. His focus is on scalable cloud-native solutions mainly based on JavaScript / Typescript deployed on the Google Cloud Platform. For two decades, Mike has taken ideas from inception to deployment, at startups or as lead for teams at larger companies. Mike can be found on Twitter, LinkedIn or at www.mikenikles.com.

Currently, he works with enterprise travel customers in the UK & Ireland as part of his role at Google Cloud.

Rate this Article

Adoption
Style

BT