evergreen/README.adoc

= Evergreen

image:https://badges.gitter.im/jenkins-infra/evergreen.svg[link="https://gitter.im/jenkins-infra/evergreen?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge"]
image:https://ci.jenkins.io/job/Infra/job/evergreen/job/master/badge/icon[link="https://ci.jenkins.io/blue/organizations/jenkins/Infra%2Fevergreen/activity",title="CI Status"]

_if you prefer IRC, check out link:https://irc.gitter.im/[irc.gitter.im]_

link:https://issues.jenkins-ci.org/secure/RapidBoard.jspa?rapidView=406[*Issue Tracker*]

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
footnoteref:[ci, https://en.wikipedia.org/wiki/Continuous_integration]
and CD
footnoteref:[cd, https://en.wikipedia.org/wiki/Continuous_delivery] 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
[source,bash]
----
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/data/ \
    -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.

[source,bash]
----
docker exec evergreen cat /evergreen/data/jenkins/home/secrets/initialAdminPassword
----


=== Getting started with an AWS-based installation

[NOTE]
====
This documentation is coming soon.
====

=== Milestones

Jenkins Evergreen is currently available for **early adopters**. Please see link:https://jenkins.io/projects/evergreen[jenkins.io/projects/evergreen] for more documentation and instructions on how to use it.

==== Milestone One


:tada:

==== Milestone Two

Currently **in-progress**

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**

==== General Availability

**Currently unplanned**


== Design Documents

Evergreen and Jenkins Evergreen are both captured in the following design
documents:

|===
| JEP | Title

| JEP-300
| link:https://github.com/jenkinsci/jep/tree/master/jep/300[Jenkins Evergreen]

| JEP-301
| link:https://github.com/jenkinsci/jep/tree/master/jep/301[Evergreen packaging for Jenkins Evergreen]

| JEP-302
| link:https://github.com/jenkinsci/jep/tree/master/jep/302[Evergreen snapshotting data safety system]

| JEP-303
| link:https://github.com/jenkinsci/jep/blob/master/jep/303[Evergreen Client Registration and Authentication]

| JEP-304
| link:https://github.com/jenkinsci/jep/tree/master/jep/304[Evergreen Client Error Telemetry Logging]

| JEP-305
| link:https://github.com/jenkinsci/jep/tree/master/jep/305[Publishing incremental commits as Maven releases]

| JEP-306
| link:https://github.com/jenkinsci/jep/tree/master/jep/306[Evergreen Instance Client Health Checking]

| JEP-307
| link:https://github.com/jenkinsci/jep/blob/master/jep/307[Evergreen Update Client/Server Lifecycle]

| JEP-308
| link:https://github.com/jenkinsci/jep/blob/master/jep/308[Evergreen Error Telemetry API]

| JEP-309
| link:https://github.com/jenkinsci/jep/blob/master/jep/309[Bill of Materials]

| JEP-310
| link:https://github.com/jenkinsci/jep/blob/master/jep/310[Evergreen AWS auto-configuration]

|===

[[deployment]]
== 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
footnote:[https://governance.openstack.org/tc/reference/opens.html]
_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

See link:HACKING.adoc[the related document].