-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
44 lines (33 loc) · 2.14 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
---
layout: default
title: Build Canaries
---
<h2>
<a id="posts" class="anchor" href="#posts" aria-hidden="true"><span class="octicon octicon-link"></span></a>Recent Posts
</h2>
{% for post in site.posts %}
{{ post.date | date: "%-d %B %Y" }} :: <a class='post-title' href="{{ post.url }}">{{ post.title }}</a><br>
{% endfor %}
<h2>
<a id="about" class="anchor" href="#about" aria-hidden="true"><span class="octicon octicon-link"></span></a>About
</h2>
<blockquote>
<p><strong>Noun</strong><br> canary in a coal mine</p>
<p>(idiomatic) Something whose sensitivity to adverse conditions makes it a useful early indicator of such
conditions; something which warns of the coming of greater danger or trouble by a deterioration in its health or
welfare.</p>
</blockquote>
<h3><a id="what" class="anchor" href="#what" aria-hidden="true"><span class="octicon octicon-link"></span></a>What?</h3>
<p>The concept of build monitors is not new, but building your own takes time and focus away from building the
actual software you want to build.</p>
<h3><a id="how" class="anchor" href="#how" aria-hidden="true"><span class="octicon octicon-link"></span></a>How?</h3>
<p>Primarily we have created a build monitor, <a href="http://nevergreen.io/">Nevergreen</a>, that we believe
can be used by most projects "out of the box". For the times this is not the case, the entire codebase of
Nevergreen is open source allowing it to be improved or completely modified by anyone in the community. We
have also extracted several libraries out of the Nevergreen source allowing them to be used directly, for
completely new and different monitor ideas.</p>
<h3><a id="why" class="anchor" href="#why" aria-hidden="true"><span class="octicon octicon-link"></span></a>Why?</h3>
<p>As teams and projects get bigger and more complicated, there are more chances for build and integration
failures. The earlier and clearer these failures are presented to the teams involved the better. You can
read more about continuous delivery here, <a href="http://www.thoughtworks.com/continuous-delivery">http://www.thoughtworks.com/continuous-delivery</a>
</p>