anchor.diff:  
   Discuss with your team what this does and how it works. In particular, review what the hombrosxx server does.
   
  +=== A first look at Jenkins
  +
   So, when hombrosxx receives the call from the githook, how does it know what to do? Go to your X-windows Firefox, and open the hombros tab with the Jenkins GUI.
   
   image::hijoInitLink.png[]
  
positive.code: 
  By this point, Jenkins' centrality should be clear. However, on this first pass through the architecture, there is one more step, that of deployment.
  
  At this time, we are not doing full Continuous Deployment in the lab, as it's not clear that this is always a best or desirable practice. You develop on manos, check into cerebro, and if all tests pass you have a newly built package in espina ready for deployment, but the actual deployment still requires one more positive step. Going back to your 
  
  Lab outline:
  
  (optional) Each team reloads their own pipeline... but not all at once.
  
  change & build, confirm local display
  
  push to master, confirm that Jenkins builds & archives to Artifactory
  
  Deploy to Cara, confirm
  
  Break something
  
  Look at all aspects of the pipeline. It's yours and if you break it we will just rebuild it.
  
  Trace a configuration setting through to the Chef recipe
  
  Start developing a product identity. As a team, develop some simple product ideas. These can be very basic things like:
  
  * Display a mascot or brand for your team
  * Take a person's name and say "Hello" back to them
  * Perform simple math calculations
  
  Take a LIMITED amount of time and come up with 3-5 such features that your developers think they can implement. Recommend doing this mostly through echoing Javascript to the HTML page, but it is up to you if you want to bring in actual Java graphical libraries.
  
  Features must have tests.
  
  
  
  == Optional suggestions
  * Build Calavera on your laptop, suggesting fixes
  
  
  
  
  
  IMPORTANT: Well, at least, you will be exercising an end to end automated build toolchain. We'll leave it for the purists to argue whether this is "doing DevOps."
  
  The key principle is that you must pull very frequently, especially if you are about to change something becausee you need to be up to date with what others have put in the repository.
  
  You need to perform the next steps in immediate order, so be sure you have some time to work uninterrupted. First, update your repository:
  
   vagrant@manos40:~/hijo$ git pull
  
  This makes sure that there aren't any changes on cerebro we don't know about.
  
  Now let's make a small change:
  
      nano src/main/java/biz/calavera/MainServlet.java
  
  ....
     package biz.calavera;
  
     //package test;
  
     import java.io.*;
     import javax.servlet.*;
     import javax.servlet.http.*;
  
     public class MainServlet extends HttpServlet {
     	// Import required java libraries
  
     	  private String message;
        private String manos41msg;  ## Lab 04 update
  
     	  public void init() throws ServletException
     	  {
     	      // Edit this message, save the file, and rebuild with Ant
                   // to see it reflected on the Web page at http://localhost:8081/MainServlet
     	      message = "This is a skeleton application-- to explore the end to end Calavera delivery framework.";
                   manos41msg = "ManosXX was here";   ## Lab 05 update
     	  }
  
     	  public void doGet(HttpServletRequest request,
     	                    HttpServletResponse response)
     	            throws ServletException, IOException
     	  {
     	      // Set response content type
     	      response.setContentType("text/html");
  
     	      // Actual logic goes here.
     	      PrintWriter out = response.getWriter();
                   Class1 oResp = new Class1(message);
     	      out.println(oResp.webMessage());
  
                   Class1 oM41Resp = new Class1(manos41msg);     ## Lab 05 update
                   out.println(oM41Resp.webMessage());       ## Lab 05 update
     	  }
  
     	  public void destroy()
     	  {
     	      // do nothing.
     	  }
     	}
  ....
  
  There are FOUR places you need to make a small update. They are identified by the comment "## Lab 05 Update."  You can make up whatever you want for your manosXXmsg string as long as it is less than 30 characters.
  
  Ok, make the updates. Now build and test:
  
      sudo ant
      [message as before, unless it fails]
  
  If your build fails, go back and review and fix. Try again until it works.
  
  When your build finally works, you should be able to curl with results like:
  
      <h1>This is a skeleton application-- to explore the end to end Calavera delivery framework.</h1>
      <h1>ManosXX was here</h1>
  
  Time is of the essence. Check it in to your local repo:
  
      git commit -a -m "ManosXX checkin"
  
  and push it to the master:
  
     git push origin master
  
  (In a real world development, you might have committed it locally many times, but this is compressed.)
  
  Now, when you push it to the master, one of two things will happen.
  
  **If you are lucky**
  
  ... you will get this:
  
  ....
  vagrant@manos41:~/hijo$ git push origin master
  Counting objects: 15, done.
  Compressing objects: 100% (6/6), done.
  Writing objects: 100% (8/8), 789 bytes | 0 bytes/s, done.
  Total 8 (delta 1), reused 0 (delta 0)
  remote:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
  remote:                                  Dload  Upload   Total   Spent    Left  Speed
  remote: 100   100  100   100    0     0   6406      0 --:--:-- --:--:-- --:--:--  6666
  remote: Scheduled polling of hijoInit
  remote: No Git consumers using SCM API plugin for: git@cerebro:/home/hijo.git
  To ssh://cerebro/home/hijo.git
     897638e..5fcfb04  master -> master
  ....
  
  If all goes well, Jenkins has now kicked off. If you are doing the lab in class, you can see builds kicking off on the Jenkins dashboard.
  
  image::Jenkins.png[]
  
  
  
  If you have X-windows running, you can open a window on the main seis660 server and type:
  
      firefox -X -no-remote
  
  and enter the URL http://127.0.0.1:8133
  
  If you do not have either of these options, you can query the Jenkins API and at least see if a build has just run. Type
  
      java -jar /mnt/public/jenkins-cli.jar -s http://127.0.0.1:8133/ console hijoInit
  
  
  
      First, clone the "Lab O4" branch of Calavera thus (DON'T FORGET TO CHANGE XX TO YOUR 2 DIGIT #!):
  
       cd
       git clone https://github.com/StThomas-SEIS660/Calavera.git -b Lab-05 --single-branch manosXX
  
      What does this do? Git repositories can be branched; a branch is a separate line of development. The Cala-dev branch gives you a single machine Vagrantfile to modify, making things a little easier for you.
  
      Review [branching basics](https://www.atlassian.com/git/tutorials/using-branches/) for an overview and [command alternatives](http://stackoverflow.com/questions/1778088/how-to-clone-a-single-branch-in-git) for explanation of the particular command.
  
negative.code: = Lab 04 (Technical) End to end DevOps-based software product management
  
  == Understand the basic pipeline
  
  === Overview
  
  In this lab, you will work as a team with an end to end DevOps pipeline.
  
  