Intro
Do you know the situation when you are working in different projects which different needs regarding your development setup? You need different versions of the same tooling or frameworks and depending on what project you are working on you have to switch back and forth. Or another scenario: You are working in a project with several developers and each developer has to setup the development instrastructure by its own on his/hers machine. A lot of time can be spent on that and always differences are appearing on the different machines, because not everyone keeps the machine up to date. Would it not be great to have an option to provide your development infrastructure with just some configuration files? Check out your code from the code repository and start developing without installing a lot of tools?
Visual Studio Code provides such options with the Remote Development Extensions. There are different options available:
- Remote Development environment via SSH
- Remote Development environment running on Windows Subsystem for Linux
- Remote Development environment via Containers
- Visual Studio Codespaces (managed or self-hosted)
The cool thing of that is, that you have installed Visual Studio Code on your local machine, but you connect to a remote environment for development. Visual Studio Code configurations and extensions are specific for a remote environment. With that it is possible to configure Visual Studio Code depending on the specific needs.
Development in a Remote Container
Following I will focus on the option to develop with Remote Containers as this is an easy way to provide a consistent and isolated development environment independent from the operating system and central available systems. As the Remote Containers functionality uses Docker (Desktop), available for Linux, MacOS and Windows, everyone in your team is able to use that. In following the example I will show, how you can prepare and use a simple Remote Container development environment for UI5. This example is of course not "production ready", but should give you a glimpse on the general setup. As pre-condition Docker (Desktop) and of course Visual Studio Code must be installed on your machine.
Remote Containers Extension
First, install the "Remote - Containers" extension in Visual Studio Code.
After installing the extension the Remote Explorer appears in Visual Studio Code.
Define the Remote Development Container
The Remote Development Container is defined in a JSON file. At the root of the project a folder .devcontainer needs to be created containing a file devcontainer.json. In this example the file has following content.
{
"name": "Test UI5 Remote Dev Container",
"dockerFile": "Dockerfile",
"settings": {
"terminal.integrated.shell.linux": "/bin/bash"
},
"extensions": [
"dbaeumer.vscode-eslint"
],
"forwardPorts": [
8080,
35729
],
"remoteUser": "node"
}The configuration values have following meaning:
- name: A free to define name.
- dockerfile: The path to the Dockerfile which defines the Docker image. It is also possible to directly use an existing Docker image or a Docker Compose file.
- settings: Settings which should be applied to Visual Studio Code. Here the default terminal is set to bash.
- extensions: Extensions which should be installed in Visual Studio Code by default. Here the ESLint extension is installed by default.
- forwardPorts: The ports which should be forwarded from the container to your localhost, to be able to access, e.g. web pages. Here port 8080 is forward on which the UI5 tooling serves the UI5 application. Port 35729 is forwarded too, for the live reload functionality.
- remoteUser: The user which is used to connect to the remote container, if not root should be used. node is a predefined user by the image I used as base (see next step).
Preparing the Docker file for the Remote Development Container
The Remote Development Container definition file references a Dockerfile, stored in the .devcontainer folder. The Dockerfile for this example has following content:
FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:14
# configure npm and install global modules
RUN npm config set @sap:registry https://npm.sap.com \
&& npm i -g @ui5/cli \
&& npm i -g yo \
&& npm i -g generator-easy-ui5
# install Chrome for testing
RUN sudo apt-get update \
&& sudo apt-get install libxss1 libappindicator1 libindicator7 -y \
&& wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb \
&& sudo apt install ./google-chrome*.deb -y The Docker file uses as base the image mcr.microsoft.com/vscode/devcontainers/javascript-node:14, which is a pre-defined image for a Node.js Remote Development Container. The image is provided by Microsoft on Docker Hub. A list of available pre-defined Remote Container images can be found here on GitHub. The used image comes with a pre-defined set of installed tools like Node, NPM, Git, etc..
The next commands in the file configures NPM to be able to access the SAP NPM repository, installs the UI5 Toolling CLI, the Yeoman Generator and the Yeoman Generator UI5 Extension (because I want to generate the scaffold for a UI5 application within the container).
The last command installs Google Chrome in the container, to be able to do headless test executions.
After the file is created, the project structure looks like following:
Starting Development in the Remote Development Container
After the preparations are done, go to the Remote Explorer, press the "+" button and select Open Current Folder in Container.
This starts the docker container (including the installation of all required remote extensions in the container).
In the lower right corner you see an information that the container is started.
By clicking on the information message, a terminal is openend in which you see the current log for the container creation.
After the creation is finished, it can be seen that we are in the Development Container in the lower left corner. Clicking on it allows you to switch to the local folder or to other containers.
Create the UI5 application scaffold
Now that we have setup the container and we are connected to it, we can start to create the UI5 application scaffold. For that a terminal is opened. And surprise: the terminal is connected to our remote container.
Next enter yo easy-ui5 and answer the questions to create the UI5 application scaffold. Using the Yeoman generator is possible, as it was installed when the Docker image was created (according to our Dockerfile). For this demo I used following inputs for the Yeoman generator:
After the generation is done and all dependencies are installed, the application scaffold is ready to run. Enter npm run serve in the terminal to run the application. The npm script serves the application using the UI5 tooling. Enter http://localhost:8080/index.html in a browser on your local machine and following output appears. The port forwarding from the container to the local machine works.
To execute tests enter npm run test in the terminal. Before doing this, make sure that in the karma-ci.conf.js file the value of array property browers is set to ChromeHeadlessNoSandbox. At time of writing this, the Yeoman UI5 generator extension has a small bug which sets the value to ChromeHeadless, which leads to an error when it is tried to start the Chrome browser in a container. After changing the file (if necessary) and executing the command, the test execution should be successful.
Tips & Tricks
Prepare standard images for your development team
Instead of storing a Dockerfile in each repository, standard Docker images should be defined which can be used in the devcontainer.json file. With that it can be ensured, that every team member (or you alone) use the same image. This approach makes it also easier to update the image (and container) within a project. Just use the well-known tag approach for the Docker Images. The defined standard Docker images can be made visible for your developers by an Artifact Repository like e.g. Nexus or Microsoft Azure DevOps Artifacts.
Use Docker with WSL2 on Windows 10 Pro/Enterprise
Docker on Windows uses either Hyper-V or WSL2 (Windows Subsystem for Linux 2). WSL2 is already a pre-condition for using Remote Containers on Windows 10 Home. My experience on Windows 10 Enterprise is, that Docker with WSL2 performs better and more stable for Remote Containers than Docker with Hyper-V. Pre-Condition to use Docker with WSL2 is Windows 10 Pro/Enterprise 2004 (as WSL2 is shipped with that release).
I used Remote Containers on MacOS with Docker Desktop without issues too.
Rebuilding a container
If the development container definition was changed (or your Dockerfile) a rebuild of the container is necessary. Normally Visual Studio Code recognizes changes in the devcontainer.json file automatically and asks for rebuilding. If not, you can trigger that manually in the Remote Explorer.
Use Docker Compose if it makes sense
Assume that you have an application with different components (e.g. db, services, UI, etc.). During development you want to start up all necessary components at once. The development container definition supports Docker Compose for that. For instance within a Monorepo you can create your different components with their own development container definition using the same Docker Compose file. Connecting to a remote container starts up all stuff defined in the Docker Compose file. With other Visual Studio Code windows you can connect to the other containers too.
Open your Git Repository directly in a container
When your Git Respository contains a development container definition, it is possible to directly open it in a container without cloning it to your local machine. This is possible via the Remote Explorer, using the option Open Repository in Container.
Summary
From my point of view Visual Studio Code Remote Container Development has a huge potential to save time and costs by providing consistent and isolated environments which can be used by every developer within a team or an organization (for instance as base for different projects). The approach can be applied for many different necessary environments, for Java Development, Node Development, Python Development ... even development for serverless functionality (like e.g. for Microsoft Azure Functions).
In the area of UI5 I see a huge potential with the
Another case I see, is to set up a development image for developing applications using the SAP Cloud Application Progamming model. Based on that image (containing all relevant SAP CAP packages, SQLite, etc.), here a standard development environment can be provided in seconds for every developer who wants to use it.
In this post I focused on the Remote Container Development on a local machine, not considering the other above mentioned Remote Development options and other options for Remote Containers. E.g. remote containers can be executed on a K8S cluster too. I also like the approach of Visual Studio Codespaces (managed or self-hosted) which would allow me to develop just in a browser on my iPad Pro connected to an external display, keyboard and mouse.
What do you think? Are you already using Visual Studio Code Remote development features. Share your experiences in the comments.
References
- SAP Managed Tags:
2 Comments
