Teach you how to automate the development of Java EE Project

J2ee| Project

Editor: In this book, pragmatic Project automation, Mike Clark offers you all the tools you need to automate your software project: one-step construction with ant (One-Step builds), with CruiseControl Build on a schedule (scheduling continuous builds), click the button to release the software, easily install and distribute the application, and monitor the build and program runs through EMAIL,RSS, your cell phone, and even lava lights (lava lamps). Methods include examples that make it easy for beginners to practice, and even proficient practitioners have more advanced topics that teach them something new. In this article, he paints a summary of the benefits of automating your project.

You are about to deliver a software version for the key demo tomorrow morning. The salesman in the suit is blowing a bubble to show off your company's new auxiliary applications to some very important rich people. Just as you are looking for a feeling on the keyboard, your boss is standing next to you to remind you that the demo may get the project or the project will be ruined. Don't have any pressure!

One-step build and test

After you enter the last line of code for those "must have" presentation features, it's almost noon. Your favorite IDE shows you the code compiles and passes the unit test. But when he combines the rest of the system, does your code work as expected? To figure it out, you updated your local workspace to synchronize files in the current version control system. Then you run the step-by-step build process for the project:

$ ant

This command compiles all the code files and runs all the unit tests for the configuration in the following ant build file.

Listing 1:
<project name= "Whizbang" default= "Test" basedir=. " >

<property name= "Build.prod.dir" location= "Build/prod"/>
<property name= "Build.test.dir" location= "Build/test"/>
<property name= "Src.dir" location= "src"/>
<property name= "Test.dir" location= "test"/>
<property name= "Vendor.lib.dir" location= "Vendor/lib"/>

<path id= "Project.classpath" >
<pathelement location= "${build.prod.dir}"/>
<pathelement location= "${build.test.dir}"/>
<fileset dir= "${vendor.lib.dir}" >
<include name= "*.jar"/>
</fileset>
</path>

<target name= "Prepare" >
<mkdir dir= "${build.prod.dir}"/>
<mkdir dir= "${build.test.dir}"/>
</target>

<target name= "Compile" depends= "prepare" >
<javac srcdir= "${src.dir}" destdir= "${build.prod.dir}" >
<classpath refid= "Project.classpath"/>
</javac>
</target>

<target name= "compile-tests" depends= "compile" >
<javac srcdir= "${test.dir}" destdir= "${build.test.dir}" >
<classpath refid= "Project.classpath"/>
</javac>
</target>

<target name= "test" depends= "compile-tests" >
<junit haltonfailure= "true" >
<classpath refid= "Project.classpath"/>
<formatter type= "brief" usefile= "false"/>
<batchtest>
<fileset dir= "${build.test.dir}"
includes= "**/*test.class"/>
</batchtest>
</junit>
</target>

</project>

When you write code, you frequently click on the handy Build button in your IDE to make sure everything is compiled. You've also been keen to see a happy green stripe (the hallmark of a unit test success) after your JUnit test passes, and then you can use the JUnit test runner to integrate into your IDE. But not everyone on the team likes the IDE as much as you do, and you don't want to have to start the IDE every time someone wants to do a build. Using the build file to separate from your IDE, everyone on the team can build and test the project in one step. (The project uses MAVEN to create a step-by-step build.) ）

Don't be surprised, the build succeeds and you realize once again that you are the greatest programmer in the world. Not only does this build process in code give you confidence, he also gives you confidence that the project can be built outside of your IDE.

It feels so good that you've uploaded the changed files and avoided the trouble. You still have a lot to do to prepare for the demo, and you need to leave earlier to go to your son's Tee-ball game game for the first time. The clock ticks ...

Bubble crisis

On the way back to the office after lunch, you notice that the project's red Lava lamp is boiling (this lamp shade has special liquid material). Oh! When you want to leave for dinner, the green lights are bubbling merrily (stating that the program is all right). After you leave, your project's planned build process tries to build and test the code on the current version control resource (versioning repository) on the machine. But there was a terrible mistake.

It's easy to keep your project running on a continuous build because you can actually create a build on the command line in one step. This means that you can easily get a computer to run the build for you all day long. Otherwise, you'll have to put a developer on the command line to build the file from now on. Instead, you use CruiseControl to automatically create builds on your project's dedicated build machine at a certain time interval, as shown in the following Config.xml file:

Listing 2:
<cruisecontrol>

<project name= "Whizbang" buildafterfailed= "false" >

<bootstrappers>
<currentbuildstatusbootstrapper
file= "Logs/whizbang/currentbuildstatus.txt"/>
</bootstrappers>

<modificationset quietperiod= ">"
<cvs localworkingcopy= "Checkout/whizbang"/>
</modificationset>

<schedule interval= ">"
<ant buildfile= "Cc-build.xml"/>
</schedule>

<log dir= "Logs/whizbang" >
<merge dir= "Checkout/whizbang/junit-results"/>
</log>

<publishers>

<currentbuildstatuspublisher
file= "Logs/whizbang/currentbuildstatus.txt"/>

<!--Email publisher-->
<!--RSS Publisher-->
<!--lava lamp publisher-->

</publishers>

</project>

</cruisecontrol>

This config.xml file causes CruiseControl to be awakened every 5 minutes, checking your project's CVS resources to see if you need to build. CruiseControl only tries to create a build when someone in your team changes an existing file or adds a new file to the version control resource. He relies on how to create a build for your project with an ant or Maven build file. You can use the CruiseControl setting to run an ant build file called Cc-build.xml, which reads:

Listing 3:
<project name= "Cc-build" default= "Build" basedir= "Checkout" >

<target name= "Build" >
<delete dir= "Whizbang"/>
<cvs command= "Co Whizbang"/>
<ant antfile= "Build.xml" dir= "Whizbang"/>
</target>

</project>

The Cc-build.xml file runs the build process by deleting a copy of your project at the last build and downloading a new copy of the project from the CVS resource. Then he automatically runs the same Bulid.xml file that you compile and test your project on the command line. After running the build file, CruiseControl publishes the results to all registered publishers. (The project using MAVEN is also CruiseControl, but it's being set up to monitor changes with some other version control systems you don't like to use)

It's a cushy job to do all these things every 5 minutes, and that's why you like to let CruiseControl do it for you. When you first set it up, it seems like a lot of trouble, but you've learned to appreciate the value of giving back your information in due time. The 5-minute scheduling task is simply to compile all the code and run the unit tests, making a quick sanity check. You also use the CruiseControl setting to run a system that performs tests at less frequent intervals. If the 5-minute build fails, the problem does not exist for more than 5 minutes. This makes it easier for you to find and fix problems, saving you valuable time. If no changes have been committed in the last 5 minutes, then CruiseControl remains dormant.

Look, the build failed! CruiseControl The red lava light is a good thing, because you may have overlooked the failed email in your inbox filled with mail. Anxious to find the root of the problem, you open the Build state Web page found in a hurry you forgot to upload a new file. It's embarrassing, but at least you can now fix the build before the demo before the problem is complicated and leads to a nightmare debugging session.

Quick release

Not long after, everyone on the team uploaded their code. Now you are ready to create a distribution file to deploy it to the demo server. But before you leave, you have only a few minutes left, and the release process includes the following tedious steps:

1. To test code in a skeleton path

2. To build a version branch on version control

3. Contents of the Proofing version branch

4. Build and test the code in the version branch

(fix all the problems)

5. Pack This version of all the files into a distribution file

6. Test the contents of the distribution file

7. Label version branches in version control

8. Send distribution documents to QA

It's just a step you can think of! In fact, publishing your software is always a time-consuming and error-prone process. As a result, you cannot regularly release new versions of your software. You are tired of having to recall all the steps in the release process and the pressure to correctly enter all the commands you need. The step-by-Step release process for your project is now automated (and even documented) with some button-operated publishing scripts.

The demo will take a little bit of preparation, and you want a stable workspace that is isolated from the active part of the program backbone. But you don't want to freeze the trunk blocking everyone's development before the next release. The solution is to create a version branch in your version control resource. The first script controls the 1 to 4 steps of the publishing process that runs the version number:

$ release_branch 2_7_1

The script ran successfully, telling you that the version branch created all the code compiled and passed the test. If there is a problem, you need to modify it in this version of the branch path to test the changes and submit the changes to the version branch. You can also run other scripts to merge these changes into the trunk.

Once you have a version of the branch, you fix all the problems and you are ready to actually generate a release version. For these, you run another script to control steps 4 through 8, giving a version number.

$ release_generate 2_7_1

The result of running this script is a separate distribution file-the same file that the customer can install and publish. You're almost done, and there's only one step left before you leave.

Dirty Deployment Details

Deployment to the demo server is another multi-step manual process, and even if you do it slowly, it basically goes wrong. But because your team needs to deploy software frequently-it's important to deploy correctly and reliably at all times-you've automated the deployment steps. When you run the deployment script, all the dirty deployment details are implemented for you.

$ deploy

In this case, the script transmits the distribution file to the demo server to unpack all the deployment modules into their respective paths. But there is one more step to be done before the script actually executes on the application server.

You don't want to deploy apps automatically, just because of a stupid configuration problem that doesn't start. Before applying a clean run, your application has a number of configuration values that need to be set appropriately. So before starting the application server, the script ran a set of diagnostic tests to quickly identify any potential problems in the deployment.

In particular, you've noticed that the database is configured with a common deployment error. Debugging this problem lets you lose a lot of hair, so last week you wrote the following diagnostic test with JUnit:

Listing 4:
public class Diagnostictests extends Junit.framework.TestCase {

public void Testdatabaseconnection () {

Database Database = new database ();

try {

Database.connect ();

catch (RuntimeException e) {
Fail ("Unable to connect to" database "+
Database.geturl () + "'." +
"Please check the ' Database.url '");
}
}
}

The Testdatabaseconnection method attempts to connect to the database using a project's database class instance. That class reads the configured value from the configuration file, just like the Database.url attribute. If the diagnostics test does not connect to the database, it looks as if the application will suffer the same fate when it is running. Therefore, if the Connect method throws an exception during a diagnostic test call, the Fail () method is invoked to print a useful message to help you fix the problem.

Thank you very much, there is no error in the deployment script report. This tells you that the application has been deployed, that all diagnostic tests have passed, and that the application server has been started. You have to show it's working!

Leak monitor

You click on a few pages of Web apps to do a quick and sound test. It looks great, but you want to know tonight that it will still be great for driving tomorrow's demo so you can sleep well. The project is online so you can know what's wrong with the demo all night.

Don't worry. You can find a program from your automated toolbox to search every few minutes for a Web site with the wrong words like "error" or "Exception." If this word appears, or if the Web site becomes unusable, the monitor will send an SMS message to your phone. In this case, if the application is dropped, you will have more time to fix it before the demo. Before you run out of the office door, you hang the monitor on the demo site:

$ monitor Http://demoserver:8080/whizbang

At the Tee-ball, you see your son on the plate. In the meantime, your reliable surveillance program runs alone in your office. Your cell phone is on the side, but he never rings, you sleep like a child because the demo will not fail to end.

Forward and upward

The demo was so successful that the client had been lined up to get a copy of the application. Submitting a distribution file to your company's Web site or burning a number of CDs will slow down your team and will be the same if there are no automated scripts to control those tasks. If someone happens to report an error, you can easily regenerate the demo from version control. When the error is corrected, you can click the button to generate a new release.

Wherever you are, automation can rely on notifying you earlier when a problem occurs to help reduce the risk of presentation failure. Automation also saves you time, ensures consistent results, and provides you with a repeatable way to build and deploy your software. As you continue to prepare for the presentation and release of new software, automation can be useful multiple times.

The actual project automation

Unfortunately, this story is not true for many projects and may include your project. Many teams try to do the chores of these projects by hand, but people do not do this repetitive work as well as the computer does. These teams risk using different methods to run a process that focuses only on a single machine, not on another machine, or on the wrong thing. Frankly, you know you have better things to do than keep building, press the multi-step list, copy files to the server, and monitor the running programs. But how can you quickly and effectively connect this piece of work together?

From this article it seems that automating your current or next project involves a lot of work. Thankfully, you don't have to automate all of your project processes today to start clarifying the benefits of automation. The chore of every project you automate is an investment that returns immediately and adds value over time. You can start quickly with free tools such as Ant,maven,cruisecontrol, JUnit, and simple scripts. Pragmatic Project Automation This book tells you how to use your computer again and again to do the repetitive tasks of your project without bothering you. That means you'll have more time and energy to do something really exciting--challenging--like writing high quality code.