Release Notes: Codenvy 5

Codenvy 5 has been released and brings all the improvements from Eclipse Che 5, plus a host of enterprise features. To learn more and get started visit our website.

With Codenvy 5 you can convert production runtimes into developer workspaces. Start with Docker or Compose, “dev mode” the workspace with agents for debugging, terminals, SSH, sync, and intellisense, and then connect any IDE, whether your favorite desktop IDE or our built-in Eclipse Che Web IDE.

Codenvy’s infrastructure and installer have been Dockerized. You can now install Codenvy in minutes on any operating system with Docker including Mac and Windows!

Execute docker run codenvy/cli start to get guided installation help, or try Codenvy for free at http://codenvy.io with self-service workspaces.

This release includes:

• Dockerized Codenvy: Install a private Codenvy anywhere Docker runs.
• Fair Source 3 (Free) User License: Built-in, non-expiring, 3 user license.
• New CLI: Offline installation, simple configuration, and data backup.
• LDAP Integration: Synchronization and authentication for LDAP / AD.
• BitBucket Server Integrations: Connect to JIRA, Jenkins and automate pull requests with BitBucket repos.
• Consolidate Databases: Because a single database is easier to manage.
• Auditing Capabilities: Track workspace usage and license compliance.
• Built-in Documentation: {your-codenvy-url}/docs to get help.

This release includes improvements from Eclipse Che 5, the world’s most popular open source cloud IDE and developer workspace server:

• Docker Compose Runtimes: Dev workspaces with multiple containers.
• Workspace Snapshots: Auto-image and auto-restore workspace state
• Workspace Agents: Inject developer services into any workspaces.
• Docker Exec Agent: Replaces docker exec with Golang REST server for executing commands.
• Stack Editor: Create stacks with your runtime, or edit and test any of our 30+ default stacks.
• Language Server Protocol: Add intellisense for any language.
• New Debuggers: Added new Node.JS and Zend PHP debuggers.
• SSH: Automatic key generation across all machines in a workspace.
• Desktop Sync: Synchronize workspaces with your local IDE.
• More Responsive: Filesystem watchers optimize file operations and browser updates.
• Split & Resize: Terminals and editors can be split and sized to your exacting requirements.
• PHP: Auto-complete, definitions, debugging and more.
• Bitnami Stacks: Certified workspace stacks for popular languages and frameworks.
• Chedir: Reproducible cloud workspaces from your local repo.

Quick Start

Install Your Own Codenvy:

Create Free Account at codenvy.io:

Sign up for a free account at codenvy.io and get 3GB RAM for your running workspaces.

Advisories

Docker 1.11+ is now required to run Codenvy on-premises, however we recommend Docker 1.12.5+ for best performance.

We are deprecating the puppet-based installation of Codenvy. This installer required CentOS 7 or RHEL as the only deployment platforms. For customers that wish to migrate from puppetized installation of Codenvy to Dockerized, contact our support team for assistance.

The machines perspective has been moved. Information about ports, server and URL mappings can be found in the Workspace > Runtime section of the user dashboard. This is a more natural and intuitive place for this information:

Dockerized Codenvy

Codenvy’s infrastructure and installer have been Dockerized. You can now install Codenvy in minutes on any operating system that supports Docker 1.11+ including Mac and Windows!

The Codenvy installation is secure and scalable. Each of Codenvy’s internal services run in separate Docker containers including Codenvy, HA Proxy, Nginx, PostgreSQL, Socat, Docker Swarm for scaling and Docker Compose for workspaces. The only dependency is Docker (we recommend 1.12.5+). Scalability is built-in with ZooKeeper and Docker Compose with a simple syntax to add additional workspace nodes by configuring Docker daemons.

The Dockerized infrastructure replaces our puppetized installer, which is still supported but deprecated. The puppetized version only supported RHEL and CentOS 7, and installation time averaged 40 minutes. The Dockerized installer supports a broader array of operating systems and boots in seconds after the ~1GB of Docker images are downloaded from DockerHub.

Install Codenvy at any time with docker run codenvy/cli start.

Fair Source (Free) User License

The Dockerized installation of Codenvy now ships with a Fair Source 3 license, which gives up to three people free usage of Codenvy without the need to install a license key and without an expiration. You can now scale as many nodes as you’d like while using a Fair Source 3 license.

New CLI

We have rewritten the CLI to make starting, stopping, configuring, and managing Codenvy fun. Docker is an amazing tool and we used it to create a cross-platform installer that works on any system where Docker is running. Key features of the CLI:

• Guided help: Enter docker run codenvy/cli start and the CLI will help you get configured.
• Proxy inheritance: Single location for setting proxy information.
• Offline installation: Install Codenvy and your stack images disconnected from the Internet.
• Single configuration: A single ‘codenvy.env’ file contains all your config.
• Backup: Store user data in one location to simplify backup and recovery.
• Scaling: Add nodes to handle additional workspaces and developers.
• Simulated Scaling: Test scaling without the need for physical nodes.
• CLI logs: Track progress with a cli.log stored in your data directory.
• Image registry: Fetch stack and Codenvy dependency images during a single pull cycle.
• Future proofing: Version compatibility check when upgrading.
• Docker Compose: CLI generates OS-specific syntax to run Codenvy.

The new CLI uses internal Docker containers such as alpine, codenvy/codenvy-ip, and puppet/puppet-agent to install a “configuration” into the folder that you volume mount into :/data. This installation will be version-controlled and will get a new codenvy.env file that has all of the properties within it that alters how Codenvy behaves. When you start Codenvy, we use our embedded Puppet container to source your properties from codenvy.env along with a set of configuration templates installed during initialization to generate an OS-specific set of runtime files that are used to start, stop and restart Codenvy on your host.

The output of a configuration is placed into the /instance folder, which will have a docker-compose.yml and a docker-compose-container.yml for starting, stopping, and restarting Codenvy either directly from your host or from within another Docker container. When you use the CLI to start Codenvy, we use (yet another) Docker container to initiate a Docker Compose up or stop sequence. While Codenvy and its various workspaces are booting, you can follow along by tailing the container output and docker logs output.

Your end users can use the same CLI to interact with their workspaces as well. We have embedded commands to connect to workspaces, SSH into workspaces, and synchronize your workspaces with your desktop IDE within the same CLI.

BitBucket Server Integrations

Codenvy’s workflow integrations with JIRA and Jenkins have now been extended to support BitBucket Server.

The JIRA integration automatically adds project-correct developer workspace factories to each new JIRA issue created (for projects and issue types you designate). A developer reading an issue in JIRA only needs to click the Codenvy link to be able to jump into a correctly configured workspace pre-setup with a BitBucket Server code branch named for the JIRA issue ID. See the short demo or read the docs.

The Jenkins integration is especially useful for diagnosing build failures. Codenvy’s plugin is added to Jenkins so that when a build failed email is created Codenvy programmatically creates a workspace template for the project, branch and commitID that resulted in the failed build. Clicking the link signficantly speeds up problem investigation for these issues. See a short demo or read the docs.

LDAP Integration and Consolidated Databases

Codenvy architecture has been simplified to use a single and consolidated database. We are now using PostgreSQL for Codenvy associated to EclipseLink as JPA backend. This makes the system easier to maintain and keep up-to-date with future versions. You can learn more about this architecture refactoring on the following issue.

Along with the simplification of the databases we are using for Codenvy, we are providing integration with a 3-part LDAP server for two major roles: synchronization and authentication. Codenvy is compatible with InetOrgPerson.schema. We support user authentication, LDAP connections, SSL, SASL, and various synchronization strategies.

The Codenvy synchronizer gets all users based on a configured list of groups or filters which need a Codenvy account. The synchronizer then creates a Codenvy User and persists the necessary fields from LDAP into the Codenvy database (the passwords are not persisted). Then the synchronizer re-evaluated and keep up-to-date the configured groups/filters: the users that no longer match the group/filters are removed, the others are updated or added as needed.

For the authentication, Codenvy will authenticate the user against the 3-part LDAP server, if the authentication is successful, the user will logically gain access to Codenvy.

You can learn more about our LDAP integration on our documentation.

Auditing

Codenvy on-premises now provides auditing capabilities giving you visibility into workspace usage as well as current and historic license changes:

You can learn more in our managing Codenvy documentation.

Docker Compose Runtimes

Codenvy workspaces have their own dedicated runtimes. Codenvy has been extended so that workspace runtimes can be defined with Docker Compose syntax or with a multi-machine stack.

This is all fancy talk for saying that you can now have a single workspace where your database and application are in different containers, connected together into a single network!

When the workspace starts, Codenvy will execute the workspace runtimes defined in your stack. The stack definition can be comprised of multiple machines, each with their own Docker image. Or, you can provide a single Docker Compose recipe within the stack which will delegate multi-machine activation to Codenvy. If you launch multiple machines in a single workspace environment, we will launch them in a virtual Docker network so that the machines will have visibility and a communication path between them. You can mount directories into the workspace as well.

Example Compose recipe for a runtime with a Java app server and MySQL:

Codenvy requires Docker Compose recipes to contain a machine named dev-machine where the workspace projects will be mounted and the Codenvy runtime dependencies injected. It is possible to mount extra volumes in the dev-machine so other machines can get access to these volumes using the command volumes_from:dev-machine. This allows the project data to be shared across several machines in the workspace.

The majority of the Docker Compose file syntax works with Codenvy. For a full list of supported syntax and workarounds for some unsupported syntax see our documentation. Or read the Workspace Administration section of our docs to get a full picture of the workspace interaction.

You can try Docker Compose workspaces with this tutorial.

Workspace Snapshots

Now you can save your workspace runtime state and your project state with a single snapshot.

In Codenvy your workspaces are a combination of your runtimes and project code. We marry these two together during the workspace activation cycle. When you stop a workspace, we save your project code to long term storage through a volume mount.

Previously, end users had to specifically request a snapshot for their runtime to save the state. Now, the default configuration is that any workspace stop event will automatically snapshot the workspace runtime (and all of its images). When starting or restarting a workspace that has a snapshot you will be asked if you want to restore from snapshot or recreate the workspace from scratch.

This behavior can be changed in the codenvy.env file:

By default workspace snapshots are saved to Codenvy’s built-in container registry, but you can configure Codenvy to save snapshots to a private registry that you have installed. This configuration is also handled in the codenvy.envfile:

Read more in our docs.

Workspace Agents

Workspace agents dynamically inject developer services to convert production runtimes into developer workspaces. Agents are used to add capabilities like Java intellisense, SSH access, debuggers, and our Web terminal into any runtime. Agents are a cross-platform way to install, start, and configure software that is essential for doing development, but usually does not exist in your production containers.

Agents can also package their dependencies as well as dependencies of project types selected by end users. For example, if you choose a Node.JS project type, then the relevant agents may include yum or npm so that when an end user opens the workspace, the utilities they need to build and run their project are ready to go.

Some agents are included and configurable by your end users. Other agents are dynamic and injected by our workspace services based upon end user activity. When creating a workspace and editing its runtime, you can enable agents for each of the machines you are using through the user dashboard.

By externalizing the developer services through agents it allows you to take a production Docker image and “dev-mode” it by enabling agents. Combining developer agents with Codenvy’s new multi-machine workspaces, it’s simple to enable developers to code on production-grade images.

Read more in our docs.

Docker Exec Agent

If you have spent any time with Docker on the command line, an essential tool for developers is running ‘docker exec’ to inject commands into a running container. Codenvy commands (the processes that run in your workspace when you select the Play button) have always been sent to your workspace runtimes using docker exec. Docker exec is great if you are working with a single command in a synchronous fashion. However, developers want more control and interactivity with the lifecycle of the commands that they run and a single Docker container needs to be able to handle simultaneous execution of many commands without disrupting the browser client that is making those commands.

We have replaced the built-in Docker exec capability with an all-new, high performance “exec agent”. This agent is a Golang-based server for executing commands within a workspace container and then streaming process output logs and command state as events over websockets.

We have open sourced this agent and it is included in the Eclipse Che repo. There are three subsystems:

1. JSON RPC 2.0 Web Socket interface
2. Events
3. REST API for starting a process, killing process, getting logs, and event subscriptions

Stack Management

Stacks define a reusable template that contains a definition for a workspace runtime, a set of commands and project configuration and metadata. Stacks, like workspaces, now support both single container and multi-container environments.

You can use Codenvy’s built-in stacks or author your own custom stacks. There is a new “Stacks” section in the user dashboard to create, edit and manage stacks — you can edit the predefined ones or use the stack’s editor to author your own custom stacks.

The built-in stacks editor allows to author your stack and test them into a temporary workspace. When testing the new stack, Codenvy spins up a temporary and isolated workspace using the stack you just defined. You can use the temporary workspace to import your project, test commands and ensure all the components you need are properly configured. Once the testing session is completed, the temporary workspace will be automatically deleted.

Read more about using and customizing stacks in our docs.

Language Server Protocol

Eclipse Che now supports the open source language server protocol that Codenvy, Red Hat and Microsoft announced in June.

Language servers provide distributed intellisense for a language and can include syntax highlighting, code analysis, error checking and auto-completion.

In Codenvy, language servers are packaged as agents and that are injected into the workspace’s dev-machine where they are installed and activated depending on the project type and the file being edited.

The language server protocol has significant momentum. There are nearly 20 planned language servers being created by the communities from different language ecosystems. Our project lead, Tyler Jewell, is particularly looking forward to the Emacs language server! With the availability and feature support for different language servers changing so frequently, we will be updating our support in each release.

Today, Codenvy supports JSON, C#, Java, PHP and TypeScript language servers.

A few examples of the 20+ language servers currently completed or in development.

Language servers for Go, Python and JavaScript are planned for contribution in Q1 of 2017 by Sourcegraph. We will be aggressively adding in support for additional language servers as they get released, and we will be working with other projects on a dynamic registry so that we can discover and add new language servers without having to do a new release of Codenvy each time.

In this version of Codenvy, we have added the following features of the language server protocol into our editor:

• Show errors and warnings inside the editor:

• Auto-completion:

• Find Definitions: searches for symbol definition and jump-navigation

• Find Reference: search project-wide references for the symbol in the given text

• Document Symbol: view and navigate document symbols

• Workspace Symbol: view and navigate symbols across a workspace

• Formatting Capabilities: document formatting, document range formatting, on type formatting

• Hover feature:

You can read about the implementation of the Language Server Protocol in the issues that were merged.

Watch the CheConf session on Language Servers:

New Debuggers

We’ve added gdb, Node.JS, and Zend PHP debuggers. You can now launch debugging servers within your workspaces for each of these services, and then configure the IDE to automatically connect to the debugger over their specialized debugging port.

Debuggers are installed and configured with the ready-to-use technology stacks provided out of the box with Codenvy. For example, if you select PHP stacks you can use the Zend Debugger for both PHP CLI scripts and PHP web apps.

The debugging workflow involves the following steps:

1. Set breakpoints in the editor.
2. Launch the debugger to start listening for a new debug session.
3. Execute the debug command for your project.
4. Use the debugger to analyze the behaviour of your project.

Read more in our docs.

SSH

Codenvy now provides automatic key generation across all machines in a workspace. If your workspace is powered by Docker Compose, then the SSH agent is deployed into every container that makes up your compose services. You can optionally remove the agent from selected machines of your compose services from within the dashboard.

Each new workspace has a default key-pair generated for it. The private key for the workspace is inserted into each machine and they will all share the same public key. You can generate a new key-pair in the dashboard (under Workspace > SSH), or remove the default one to replace it with your own.

You can then use various utilities for connecting to a workspace using SSH with our Docker containers, the Codenvy CLI, or your off-the-shelf SSH client on your desktop.

SSH with Codenvy CLI:

Read more in our docs.

Desktop Sync

You can now use any IDE with your Codenvy workspaces. We have built a fast, Fuse-based mount and sync utility for your workspaces. The sync utility connects to a workspace and synchronizes the project files to a local file system. The utility works on every operating system including Linux, Mac, and Windows with the same syntax (no need to install crazy tools like Windows Putty to do SSH). Of course, Docker came to the rescue here, as the synchronizer is built into the new CLI.

Synchronizing your project files lets you have an offline / online mechanism. It also allows you to use any desktop IDE with your local project files. The synchronizer runs in the background and developers can work with their hosted Codenvy workspaces or with their desktop IDE and the file modifications are synchronized every couple of seconds.

Our mount utility (provided by Eclipse Che) is built with a Docker container eclipse/che-mount, inside of it, we create an sshfs connection to the remote workspace using your username, password, and workspace port number. We then use unison, a file system synchronizer, to synchronize the contents of the remote workspace with a directory in the container. Your localhost volume mounts the synchronized directory and files are shared. The unison synchronizer is run every minute, and will capture both changes made locally on your host and any changes made in the remote workspace.

To synchronize your local IDE:

This will make a secure connection to the workspace and unison sync the contents to the local host directory.

The default synchronizes everything in your workspace’s /projects folder. The size and nature (binary vs. text) of the files within your workspace affect the time it takes to complete a synchronization. If you have libraries such as with an NPM or maven repository, it may be unnecessary and taxing to synchronization all of those files.

You can improve synchronization performance by providing a unison profile. A unison profile allows you to specify path specifications of files that must be included or ignored, and there are multiple tactics for specifying the list including regex and directory pattern matching.

You provide a unison profile as a *.prf file within a folder on your local computer and then volume mount the folder containing that folder with an additional Docker option when using the CLI: -v <path-to-unison-file>:/unison.

See examples more in our docs.

Split & Resize: Terminals and Editors

Split, size, split again, and resize. You can now manipulate the terminal and editor windows to divide your workspace into your ideal layout. You can split views horizontally and vertically, and then move the split to create the view size that you want. Files that are opened within the editor can be targeted for a particular pane, and terminal command output is also pinned to the output window that you want.

You can also quickly maximize the size of a panel by using the quick option icon in the top right corner. Alternatively, you can get a fullscreen editor by just double-clicking on its tab. The same behaviour applies to the processes panel, so enjoy a fullscreen terminal or console output window right now!

Read more in our docs.

Rich PHP Support

Everyone give the great engineers at Zend, a Rogue Wave company, a big round of applause! They worked night and day to expand the PHP support within Eclipse Che. Codenvy gets this goodness automatically as it is based on Eclipse Che. There are new PHP stacks with certified PHP runtimes, PHP project types within the wizard, PHP project templates, PHP syntax highlighting, Zend debugger, and a PHP language server for eat-your-heart-out PHP intellisense.

If you activate the PHP intellisense agent, you’ll get code completion, syntax analysis and validation, formatting tools, symbols resolution as well as a set of features to navigate to definition and find references. Those features are provided by an open source language server implementation for PHP which has been integrated into Codenvy. This language server is implemented in pure PHP and made by the PHP community itself.

Built-in Documentation

You can now access Codenvy documentation for your installed version without internet access by navigating to <your-codenvy-url>/docs. You can also access docs from the footer of the user dashboard.

As part of this change, Codenvy documentation has been repackaged into markdown files so that documentation changes can be tracked with PRs similar to how we manage code changes. We then use Jekyll to convert markdown into static HTML that is pushed to the Codenvy site from our CI system each night.

Performance Improvements

Architectural changes in Eclipse Che were made in order to optimize file operations. These were brought into Codenvy as well.

A new file watcher sub-system has been added, which tracks and generates events for portions of the workspace file system, project structure, or individual files within the workspace. Our client-side extensions and plugins register new file watchers that contain the minimum sets of folders and files that need to be watched for updates, and within the system any modifications to those files are monitored in real time for broadcast to the IDE. There is dynamic registration of file watchers for important resources. For example, we register a watcher for a specific path only if it is expanded in the project tree folders.

Files opened in the browser IDE are always updated in real time to reflect any changes when:

• Several users are using a single workspace.
• Several clients (local IDE sync, SSH sync) are using a single workspace.
• Several browser IDEs used in different tabs.

You can learn more in the following epic.

Bitnami Stacks

Bitnami provides certified workspace stacks for popular programming languages and frameworks. The stacks are integrated with Codenvy and make development frameworks simple to access and use. Each framework comes pre-installed and configured in the stack. You can go from thinking about a new app, to coding it, in just a few minutes. Pretty easy and fun!

Certified Bitnami workspace stacks for Express, Laravel, Rails, Symfony, Play, CodeIgniter and Swift are currently available in Codenvy. And because Bitnami engineers want to make your containers as lean as possible, they are providing these stacks using the minimalist Debian-based Docker image Minideb (learn more about minideb images in this article).

Get started with Codenvy and Bitnami workspace stacks.

Other Enhancements

• Navigate to file is no longer case sensitive (#3573)
• Workspaces are auto-snapshotted by default (#937, #3419)
• Allow workspace start to be cancelled in-progress (#1534)
• Add possibility to configure logback host/port (#1513)
• Refactor projects backuping (#1371)
• Restyled maintenance page (#1384)
• Admin capabilities ‘Workspace Cap’ (#792)
• Display codenvy version in dashboard’s footer (#1273)
• Add node URL to the error logging during workspace backup/restore (#1279)
• Add CPU limits configuration (#1285)
• Add rsyslog container to collect logs (#1208)
• Add ping mechanism for checking state of workspace agent (#817)
• New loader displayed while transitioning from dashboard to IDE (#868)
• Add Organization API (#877)
• Add editor for the factory detail’s page (#827)
• Add notifications for ram limits reached on on-prem installed system (#809, #501)
• Add ability to register multiple AWS ECR registries per on-prem installation (#761)
• Factory adapter for previous formats (#787)
• Add environment variables to workspace configuration (#758)
• Add pagination to factory list screen (#679)
• New factory template (#682)

You can also read about all the enhancements in Eclipse Che that Codenvy benefits from: Eclipse Che 5.0 Release Note.

Notable Bug Fixes

• Clicking on element in project explorer jumps to the top of the tree (#1488)
• Fixed cleanup for deleted workspaces (#829)
• Fixed pull request panel initialization and prevent PR flow failure (#971)
• Fixed installation script failure when “eth0” is not configured on installation machine (#922)
• Fixed potential leak in IDE iframe injection (#839)
• Fixed update of hostname of Codenvy on-prem with multiple machine nodes (#805)
• Fixed error message with memory limits when starting workspace from factory (#771)
• Fixed “copy to clipboard” for factory URL (#679)
• Fixed legal check for legal on-prem usage according to licensing (#679)
• You can read the other notable bug fixes that Codenvy benefits from Eclipse Che: Eclipse Che 5.0 Release Note

API Changes

• Change workspace environment model (#635)
• Remove workspace.name from model (#2652)

Already a Codenvy user? Leave a review for us (good or bad) on G2Crowd, Slant, or GetApp.