Jenkins, the definitive guide, extract.

Today I am not giving my opinion about this book, "Jenkins: The Definitive Guide", but, if I would, I would be a good opinion, it is a definitive guide, it is quite complete and didactic. I read it through in my company today, and I want to remark the next paragraph:

"Introducing Continuous Integration into Your Organization

Continuous Integration is not an all-or-nothing affair. In fact, introducing CI into an
organization takes you on a path that progresses through several distinct phases. Each
of these phases involves incremental improvements to the technical infrastructure as
well as, perhaps more importantly, improvements in the practices and culture of the
development team itself. In the following paragraphs, I have tried to paint an approx-
imate picture of each phase.

Phase 1—No Build Server

Initially, the team has no central build server of any kind. Software is built manually
on a developer’s machine, though it may use an Ant script or similar to do so. Source
code may be stored in a central source code repository, but developers do not neces-
sarily commit their changes on a regular basis. Some time before a release is scheduled,
a developer manually integrates the changes, a process which is generally associated
with pain and suffering.

Phase 2—Nightly Builds

In this phase, the team has a build server, and automated builds are scheduled on a
regular (typically nightly) basis. This build simply compiles the code, as there are no
reliable or repeatable unit tests. Indeed, automated tests, if they are written, are not a
mandatory part of the build process, and may well not run correctly at all. However
developers now commit their changes regularly, at least at the end of every day. If a
developer commits code changes that conflict with another developer’s work, the build
server alerts the team via email the following morning. Nevertheless, the team still tends
to use the build server for information purposes only—they feel little obligation to fix
a broken build immediately, and builds may stay broken on the build server for some
time.

Phase 3—Nightly Builds and Basic Automated Tests

The team is now starting to take Continuous Integration and automated testing more
seriously. The build server is configured to kick off a build whenever new code is com-
mitted to the version control system, and team members are able to easily see what
changes in the source code triggered a particular build, and what issues these changes
address. In addition, the build script compiles the application and runs a set of auto-
mated unit and/or integration tests. In addition to email, the build server also alerts
team members of integration issues using more proactive channels such as Instant
Messaging. Broken builds are now generally fixed quickly.

6 | Chapter 1: Introducing Jenkins

Phase 4—Enter the Metrics

Automated code quality and code coverage metrics are now run to help evaluate the
quality of the code base and (to some extent, at least) the relevance and effectiveness
of the tests. The code quality build also automatically generates API documentation
for the application. All this helps teams keep the quality of the code base high, alerting
team members if good testing practices are slipping. The team has also set up a “build
radiator,” a dashboard view of the project status that is displayed on a prominent screen
visible to all team members.

Phase 5—Getting More Serious About Testing

The benefits of Continuous Integration are closely related to solid testing practices.
Now, practices like Test-Driven Development are more widely practiced, resulting in
a growing confidence in the results of the automated builds. The application is no longer
simply compiled and tested, but if the tests pass, it is automatically deployed to an
application server for more comprehensive end-to-end tests and performance tests.

Phase 6—Automated Acceptance Tests and More Automated
Deployment

Acceptance-Test Driven Development is practiced, guiding development efforts and
providing high-level reporting on the state of the project. These automated tests use
Behavior-Driven Development and Acceptance-Test Driven Development tools to act
as communication and documentation tools and documentation as much as testing
tools, publishing reports on test results in business terms that non-developers can un-
derstand. Since these high-level tests are automated at an early stage in the development
process, they also provide a clear idea of what features have been implemented, and
which remain to be done. The application is automatically deployed into test environ-
ments for testing by the QA team either as changes are committed, or on a nightly basis;
a version can be deployed (or “promoted”) to UAT and possibly production environ-
ments using a manually-triggered build when testers consider it ready. The team is also
capable of using the build server to back out a release, rolling back to a previous release,
if something goes horribly wrong.

Phase 7—Continuous Deployment

Confidence in the automated unit, integration and acceptance tests is now such that
teams can apply the automated deployment techniques developed in the previous phase
to push out new changes directly into production.

Introducing Continuous Integration into Your Organization | 7

The progression between levels here is of course somewhat approximate, and may not
always match real-world situations. For example, you may well introduce automated
web tests before integrating code quality and code coverage reporting. However, it
should give a general idea of how implementing a Continuous Integration strategy in
a real world organization generally works."

One of the best explanations about how to get into Continuous Integration in a coherent way. I hope the author (John Ferguson Smart) don't mind I took this paragraph, I am advertising the book in exchange!

Book of the month: Ender's Game

It did not take me three months to read it, neh? Indeed, I have not finished reading it yet, but I have to make the most of my spare time and I will write as much as I could today.

Ender's Game tell us about the solitude of the power, the hard of being a highly-gifted person and the jealousies it brings. How respect is won through excellence and not by fear or threatens. It is a model where the best are isolated in order to get the most of them.

It is curious that, during the reading of this book, I have also read this:

http://www.stanfordalumni.org/news/magazine/2007/marapr/features/dweck.html
Explanation in Spanish: http://www.cookingideas.es/el-efecto-del-esfuerzo-20110424.html

They, a sci-fi book about highly-gifted and an English research, met in a similar way to educate children in order to keep high the motivation (or how to squeeze their brains up). The main idea, do not tag a child as bad, do not tag a child as good. Although a craft may be perfect, it is the craftsman can always learn. Do not tell your child he is in the top because he can stop learning.

ps: in the last months all I've read is Isaac Asimov's some novels, they are enjoyable, but except "I Robot", the rest of the Robots novels do not teach so much. That's the reason I have not write a word about book recommendations.

Book of the month: Scrum and XP from the Trenches

I promised myself to keep reading about tools, programming languages and methodologies and to try to read one book every month. Well, I already keep reading, this is time for:

Scrum and XP from the Trenches (Enterprise Software Development)

I liked it, I am not a Scrum practitioner yet, but I took a few interesting ideas. I liked the Spanish translation, so, you can imagine, I can not judge the language style of English version. What I liked the most is the simplification of methodology to a pragmatic point, to do only things that work.

Some ideas to keep in mind:

- Prediction of project length by poker gaming. Fun!
- Digitalize it all is not that important, a wall with tacks and post-its is as useful, or more, than a colourfull web application.
- Day of research and learning.
- Situation of members in a room is important.
- SCRUM methodology from a pragmatic and useful point of view.
- and so on...

I got a free digital version (legal, it ensures), but that web no longer exists.

Next month, I hope I will have learned something about stress testing.

Keeping the reading up! See you..



[Edited] Thanks Javier Del Palacio for your corrections again, they are always welcome :)

Essential readings: Pragmatic Programmer

Pragmatic Programmer
by Andrew Hunt and David Thoma. 1999.


(33$ kindle edition, 29$ paperback edition in Amazon.
Incredible, <españolada>we are all crazy</españolada>).

When I came to Barcelona in 1997, this was the first task in my first serious job. I was asked to read this book in order to understand the basis of their job, and I found it quite illuminating. I want to spread this good practice :)

In my humble point of view, this is a great compilation of good practices about programming, and simply being, as you may read below:

[From the book]
While software development is immune from almost all physical laws, entropy hits us hard. Entropy is a term from physics that refers to the amount of ``disorder’’ in a system. Unfortunately, the laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum. When disorder increases in software, programmers call it ``software rot.’‘
There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project. Even if you are a team of one, your project’s psychology can be a very delicate thing. Despite the best laid plans and the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature’s tendency toward disorder and manage to come out pretty well.
What makes the difference?
In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict .
A broken window.
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
The ``Broken Window Theory’’ has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

Don’t Live with Broken Windows

Don’t leave ``broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.
We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.
You may be thinking that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you’d better plan on getting a dumpster, or moving to another neighborhood. Don’t let entropy win.

From: http://pragprog.com