Go to file
R. Tyler Croy 6f2211b12b
Merge pull request #252 from mandie722/JENKINS-53257_client_deletes
[Jenkins 53257] client deletes
2018-09-14 13:27:53 -07:00
distribution Merge pull request #252 from mandie722/JENKINS-53257_client_deletes 2018-09-14 13:27:53 -07:00
docs [JENKINS-53147] Essentials => Evergreen rebranding 2018-08-21 22:08:16 +02:00
services Merge pull request #255 from rtyler/updated-plugins 2018-09-14 14:20:49 -04:00
tools Refactor the client to use rely solely on socket.io for improved reliability on authentication errors 2018-09-13 10:34:13 -07:00
.dockerignore Refactor the acceptance tests to be separated into offline and online 2018-05-15 13:02:09 -07:00
.gitignore [JENKINS-49864] Test docker CLI presence 2018-03-11 21:56:00 +01:00
HACKING.adoc Fix make run 2018-08-31 13:57:14 +02:00
Jenkinsfile Incorporate building the distribution into the Jenkins Pipeline 2018-09-06 10:02:20 -07:00
LICENSE.txt License properly as MIT, and include the Four Opens 2018-02-28 10:36:32 -08:00
Makefile [JENKINS-52194] Publish the backend container 2018-06-26 21:14:34 +02:00
README.adoc Also docker pull the image before running 2018-08-30 08:58:41 +02:00
activate Move the ui code over into the client, and just let the client serve it 2018-08-29 10:55:56 -07:00
node.mk Refactor some common node GNu/Make tooling up into the root directory 2018-08-29 07:16:39 -07:00

README.adoc

<html lang="en"> <head> </head>

Evergreen

evergreen icon

if you prefer IRC, check out irc.gitter.im

Evergreen is an automatically updating rolling distribution system for Jenkins It consists of server-side, and client-side components to support a Chrome-like upgrade experience for Jenkins users.

Jenkins Evergreen provides the end-user with a pre-assembled collection of legos that can be immediately used to implement CI [1] and CD [2] workloads. At the same time, this focus on end-users success in these well-defined scenarios will help the Jenkins project develop new features, and fix bugs, more rapidly than before.

Getting Started

Evergreen is currently in alpha and is not recommended for production just yet.

Getting started with a Docker-based installation

The easiest way to get started with Jenkins Evergreen is to use the Docker image which has already been auto-configured for running workloads on Docker itself. When jenkins/evergreen:docker-cloud is launched, it will automatically download the latest version of Jenkins and the most essential plugins and automatically configure some basic authentication, Docker settings and Jenkins Pipeline.

In the example below, Jenkins Evergreen will be made available on port 8080 and persist its data in $PWD/jenkins-home, allowing the container to be restarted if necessary.

Starting Jenkins Evergreen
docker volume create jenkins-evergreen-data && \
docker pull jenkins/evergreen:docker-cloud && \
docker run --name evergreen \
    --restart=always \
    -ti \
    -p 8080:80 \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v jenkins-evergreen-data:/evergreen/ \
    -e LOG_LEVEL=debug \
    jenkins/evergreen:docker-cloud

Fetching the administrator password

Once Jenkins has been configured and run, you will need to fetch the dynamically generated administrator password in order to log in.

docker exec evergreen cat /evergreen/jenkins/home/secrets/initialAdminPassword

Getting started with an AWS-based installation

Note

This documentation is coming soon.

Milestones

Jenkins Evergreen is currently pre-release software, with a few upcoming milestones of development.

Milestone One

The first milestone of Jenkins Evergreen is to provide the first full-update-cycle of the Evergreen distribution mechanism. Like the first wire stretched across suspension bridges the goal of Milestone One is to build the tooling necessary to deliver the "bigger parts" of Jenkins Evergreen.

The bare minimum components to support subsequent continuously delivered milestones as:

  • Packaged Jenkins + evergreen-client inside of a Docker container.

  • Safe upgrade system implemented for Jenkins Evergreen to tolerate Deployment failures.

  • Minimum Evergreen backend services necessary to coordinate new upgrades for connected Jenkins Evergreen Instances, including:

    • Capturing basic error telemetry to determine whether a new Deployment was successful.

    • Maintaining long-lived connections with Instances

    • Storing "Status" information for connected Instances.

  • Basic demonstration of pre-configuration of Jenkins Evergreen with "automatically sane defaults"

  • Development workflow for identifying and managing new "versions" of Jenkins Evergreen for Deployment.

Milestone Two

Currently unplanned

The second milestone for Jenkins Evergreen is much more focused on the end-user experience while exercising the continuous delivery process built out in Milestone One.

Beta

Currently unplanned

Public Release

Currently unplanned

Deployment

The model applied with the Evergreen distribution system is one similar to "deploying" Software-as-a-Service, without having a centralized "production" environment. When documentation refers to a "Deployment", that entails a new "Upgrade" of Jenkins Evergreen being made available in the Evergreen hosted service layer, and the backend orchestration necessary to ping connected Instances to initiate their local upgrade process.

A Deployment is then considered successful when all connected Jenkins Evergreen Instances are running that new version of Jenkins Evergreen.

The Four Opens

Inspired by the Openstack project [3] Jenkins Evergreen follows "The Four Opens":

Open Source

We do not produce “open core” software.

We are committed to creating truly open source software that is usable and scalable. Truly open source software is not feature or performance limited and is not crippled.

We use the MIT license.

Open Design

We are committed to an open design process. The development cycle requires active collaboration to gather requirements and write specifications for upcoming releases. Those events, which are open to anyone, include users, developers, and upstream projects. We gather requirements, define priorities and flesh out technical design to guide development for the next development cycle.

The community controls the design process. You can help make this software meet your needs.

Open Development

We maintain a publicly available source code repository through the entire development process. We do public code reviews. We have public roadmaps. This makes participation simpler, allows users to follow the development process and participate in QA at an early stage.

Open Community

One of our core goals is to maintain a healthy, vibrant developer and user community. Most decisions are made using a lazy consensus model. All processes are documented, open and transparent.

Hacking on the project

</html>