Email Notifications are Failing Due to Curse Words

A client recently complained that Anthill was no longer sending out email notifications for their builds.  I knew that no configuration changes had occurred within Anthill.  The previous day, emails were successfully being sent out.  I also knew that the email server was working as expected.  I saw in the Anthill server logs that Anthill was still sending out the emails.

It became apparent that emails were being blocked by the email server when someone received a warning email notifying that the email was blocked because of the use of inappropriate language within the email.  I thought that was very strange.

I reviewed the project configuration as well as the build log within the Anthill UI and couldn't find any reason why the email server might think that inappropriate language was being used.  I then started analyzing what content gets included in the email notifications.  I noticed that the changelog with comments was part of the email template the notification scheme was using. 

After reviewing the comments within the changelog, I discovered the issue.  

I found a comment like this 

     "This code is total shi$."  

I used a $ in the comment above to avoid the potential that this blog article might be blocked from getting to you ;-)

This curse word could cause all future build emails to fail for a few months (depending upon the applications release schedule) if the changelog set was configured to a status that was associated with a deployment environment further down the development pipeline (like PROD). 

After having a good laugh with the offending developer (a non confrontational way of making sure that they don't do that again) I contacted the SCM administrators and asked them to change the comment.  

Strange issue and now, problem solved! 

Build Farm Anthill Agent Variable Utilization

Build Farm Anthill Agent Variable Usage.

For your build farm Anthill agents, creating agent variables for use at build time can help you to manage different versions of installed software and to make sure that your builds are using the version that you intend.

Do This:
Prefer to use agent variables with the major version in the name of the agent and do not include the minor version.  For example, for Java 1.6 builds, prefer the agent variable name JAVA16_HOME over the name JAVE16026_HOME.




An advantage of this is that future builds will automatically take advantage of JAVA 1.6 bugfix/security upgrades on your build farm machine.  One potential but rare pitfall is that a build that you created in the past is no longer easily reproducible (binary compatible) since the underlying compiler has changed.  To reproduce would involve determining exactly which version of the JDK that was originally used and then configure the Anthill build job to use that original JDK.

Don't Do This:
Do not use Agent variable names that are too generic, especially if you have more than one version of software installed on a build farm machine.  If you define an agent variable named JAVA_HOME, then someone is going to use it.  As your build farm is maintained, a newer major version might be installed and JAVA_HOME might be reset to this new version.  You may not discover until deploy time that the web container does not support that new version.  If you have the major part of the version number in the agent variable name, then it will be clear exactly what version of the software your application is using rather than having to guess when you see "JAVA_HOME" in the Ant Builder step.

Eric Starr http://anthillizer.com

AnthillPro: CVSNT Labeling Fails During the Build

If you come across a failed labeling step with a “cvsnt server: nothing known about ???” error, this could indicate that you have two files/folders that are spelled the same but with differing capitalization.

If your Source Control Software is running on UNIX which is case sensitive (therefore allowing two folders to be spelled the same but with different capitalization) and your Build Machine is a Windows machine (which by default is case in-sensitive) then when the Anthill Build workflow attempts to Label the code after the compilation, you will receive this kind of an error.

command line: cvs tag
 cvsnt server: nothing known about .folder
 cvsnt server: nothing known about myFile.txt
 cvsnt [server aborted]: correct the above errors first!
 command exit code: 1

You will need to get the application team to rename one of their directories so that they differ on more than just capitalization... and your problems will disappear during the next build attempt.

Another tricky labeling error that I have seen is when some of the code was deleted prior to the labeling step.

Effective Use of AnthillPro through the Entire ALM

I have heard of organizations that use AnthillPro solely for building their software applications while continuing to deploy their applications manually.  While AnthillPro can do a great job of building software applications, I can't help but think of this as if someone is using their brand new SUV merely for its great air conditioning.  It does a great job for what you are using it for but it was really meant to take you somewhere.

AnthillPro is essentially a workflow engine.  Anything that can be done via command line and is deterministic can be accomplished using AnthillPro.

Complex deployments to various environments, with environment specific configuration files, with the stopping and starting of processes, become trivial and routine... literally push button.

I have heard people say "our application is way too complex and important and cannot be automated".  I would say that if your application is that complex and that important, then you shouldn't risk building or deploying it manually.  I have yet to discover a manually built or deployed application that would not benefit greatly from automation and AnthillPro and the more complex the application the more adamant I would be about its potential benefits.

AnthillPro does not write your software for you, nor does AnthillPro maintain your run-time environments.  AnthillPro does not replace the need for good Software Developers or System Administrators.  AnthillPro allows your Software developers and System Administrators to do what they do best which is develop great software or maintain an optimally running System while removing the highly error prone, tedious and time consuming tasks involved with building or deploying your software.  The productivity and efficiency gains for Software Developers and System Administrators are really quite impressive, but the greatest benefit in my opinion is to the end user... the inherent reliability gains of software that was built and then deployed the exact same way every time through its entire application life-cycle (ALM).

Eric Starr
http://anthillizer.com

AnthillPro: Partial Deployments - Good or Bad

Have you ever deployed to your production environment only to discover that something went terribly wrong and you have no idea how to roll back to what you had before. If so, then you were probably doing partial deployments.

AntillPro, by design, has an extremely powerful yet simple concept which encourages full builds and deployments. By clicking on the status that is associated with the environment that you have deployed to, for example "prod", you can view all of the past build lives that have been deployed to that environment.  To rollback to the previous release all you have to do is to deploy the previous build life with that same status.

With such an easy rollback model, partial deployments should be a thing of the past.  And if you have ever used partial deployments and gotten lost in the confusion (like I have) then you can probably testify why full deployments are critical to reduce the risk of deploying the wrong version of files.

There are some occasions where the deployment of your entire application takes way to long when all you really wanted to do was to update a properties file.  In that case, you may want to create a separate "properties" Anthill project that is used to only deploy your properties files (or configuration files). By treating the properties as a completely separate Anthill project, you get the benefit of seeing which version of the properties is in each environment while by looking at the projects dashboard and can perform rollbacks as needed just like you did for the main application.

If the deployments of your application are quick enough for you, then I suggest that you keep the properties and configuration files  along with the main application rather than splitting them up.

AnthillPro: Beginner Asks How to use a Deploy Script

Recently, someone asked me for some advice.  I decided to make this into a Blog article since those that are brand new or evaluating AnthillPro may have the same kinds of questions.

I am not sure how to best handle delivering the code to the remote web server. I can get it to a working directory on the server using the standard AHP steps, but once it is there I need to stop windows services, remove an existing directory, and then move the code to the proper location. Doing this with scripts is easy enough, but how do you clean up the script afterward? I don’t see a clean workspace step for non-originating workflows, and I am not sure how to tell the agent to run a script that is stored on the AHP server.

My Answer (slightly edited for this article):

If you use a "shell" Builder step during your deploy job, you can paste the contents of your script right into that step.

If you ever have a file that you want to remove, then you can use a Shell Builder step to run the command "del myfile.txt" or whatever it happens to be called.

If you are wanting to keep your deployment script under source control (probably not a bad idea) you can use a different "Artifact Set" during the build to pick up the deployment script, and then lay it down during deployment using the "Resolve My Artifacts" step before you call the script using a "shell" Builder in the next step.

AnthillPro - Using ANT for Common Tasks

There are countless ways to solve a lot of the common tasks within Anthill workflows.  One possible way is that I could install a tool that accomplishes this task and then place this tool in the PATH so that I can run this tool from a Shell Builder.  That is a great way to "extend" AnthillPro by gaining access to the tool you need.  As I often explain to people, if you can do something on the command line, it can be done within AnthillPro.

It is not always desirable to install an extra tool and in some cases just isn't needed. I also tend to shy away from installing any extra tools on the deployment machines.

Let's say that I require a ZIP or Unzip utility... I could easily download 7-Zip and place it on my path and run it from a command shell.  Another way I could accomplish the same task if I was working with Java binary artifacts (JAR, WAR, EAR, etc...) is I could use Java's built in JAR utility from a command shell.  I could also download my favorite scripting  tool (Ruby, Python, Perl) or even use the embedded support for Beanshell or Groovy or ANT that comes with every Anthill Agent installation.

Any of these will work.  The question is, which one is the best solution?  The answer to this question might depend upon the expertise within your team of AnthillPro Automation Engineers.  Many times I see people picking a tool that they are the most familiar with rather than thinking through what would be the best tool to use for the entire organization.  If you are the "Ruby expert" in your group but nobody else knows it all that well then Ruby is a poor choice.  You may not be able to choose a tool that everyone knows but you can pick a tool that is known by a lot of people or can easily be learned... at least well enough to accomplish simple tasks.

I would like to suggest that one of the best tools you could use is ANT.  ANT is XML based so its readable and quite easy for developers and technically inclined non-developers to pick up quickly.  Another benefit is that every installation of an Anthill agent comes with an embedded version of ANT within the opt folder under where the agent is installed.  Ant is really quite simple to use.

Now, back to the required need for a ZIP utility.  Here is a simple ZIP utility using ANT.

<?xml version="1.0" encoding="UTF-8"?>
<project name="zip-script" default="zip" basedir=".">

   <property name="project-name" value="${proj.project-name}" />
   <property name="folder-to-zip" value="${proj.folder-to-zip}" />   
   <property name="unzip-destination" value="${proj.unzip-destination}" />

   <target name="clean">
      <delete file="${project-name}.zip" />
      <delete dir="${unzip-destination}" />
   </target>

   <target name="zip">
      <zip destfile="${project-name}.zip" basedir="${folder-to-zip}" excludes="paystub*.*" />
   </target>

   <target name="unzip">
      <unzip src="${project-name}.zip" dest="${unzip-destination}" />
   </target>

</project>

All you need now is to create an ANT builder step in your job and then pass in the required parameters in the "properties" tab of the ANT builder.
    -Dproj.project-name=myProjectName
    -Dproj.folder-to-zip=theFolderName
    -Dproj.unzip-destination=theUnzipDestination

This script can then be copied to be used across all of your projects and all you have to do is pass in the appropriate parameters.

Using ANT for common tasks is really quite powerful and also very simple.  If the core ANT tasks  do not give you what you need, chances are that someone has already created an extension to ANT that will provide your needed functionality.

You can read more about ANT here:  http://ant.apache.org/manual/

Eric Starr
http://anthillizer.com