Once you have the basic build going and delivering the artifacts to Codestation (see Setting Up a Build), you are ready to create a Continuous Integration (CI) build process. To get the most out of CI, the build process can be supplemented with the following AnthillPro features:
Trigger. When a trigger is activated for a build workflow, AnthillPro will automatically kick off a CI build when source changes are detected.
Notifications. Send an e-mail to users when a workflow completes.
Test integration. Integrate unit testing into your AnthillPro CI build workflow.
It's worth noting that you can add these "CI" features to your build process without having to practice CI. All the CI features either add automation or extend ease of use to every build.
Before you continue, make sure you have a consistent build going. If your project has a few successful builds, that will make it easier to troubleshoot problems as you add CI components to the build process (see Setting Up a Build). To start notifying team members about the state of the build, you will also need administrative access to your e-mail server.
Enabled on the workflow, a trigger is an automated mechanism for kicking off a process. In relation to CI, the trigger will allow for automated builds. In AnthillPro, you can use one of three trigger types to kick off a build:
Scheduled trigger. The simplest type to configure, the scheduled trigger fires either on a regular interval (e.g., every few minutes, hours, etc.) or can utilize a Cron expression for irregular, but recurring, schedules. When used for CI, the scheduled trigger polls the SCM for source changes. If changes are found, a build is kicked off. See Use Agent Filters and Quiet Periods for more detailed information.
Repository trigger. Many SCM types support commit triggers that allow AnthillPro to kick off a build at the time source changes are made. Repository triggers are far more efficient than scheduled triggers, as they don't poll the SCM, and are the most common trigger type used for CI builds. See Use Agent Filters and Quiet Periods for more detailed information.
Event trigger. An advanced trigger type, the event trigger allows for a custom filter that taps into the AnthillPro event service and triggers actions when certain events occur. For example, an event trigger would listen for build completed events, check those events against the project's dependencies, and force a build of the project if a dependency builds successfully.
When setting up your first CI build in AnthillPro, using the "Every 15 minutes" schedule for your trigger is the simplest way to get the build going. The schedule was designed to be used in conjunction with the CI trigger.
To begin, activate a scheduled trigger:
Go to Administration and select the workflow of the project you created in the Setting Up a Build section.
On the Workflow page, select the Triggers tab and then click the New Trigger button.
Select Scheduled Trigger from the drop-down menu and click Select.
Configure trigger:
Name. Give a name that identifies this trigger. For example, "CI Trigger."
Schedule. From the drop-down menu, select the "Every 15 minutes" schedule that ships with AnthillPro. This is the default schedule to be used in conjunction with CI. Fifteen minutes is a good interval for CI, in that it allows for quick feedback and avoids unnecessary builds.
Force. By default, AnthillPro does not force a build if the trigger does not find any code changes when it polls the SCM. It is rare that you will want to force a build every time the trigger fires, so leave this filed blank.
Enabled. By default, when you create a new trigger it is enabled, which is what you want for a CI build.
Click Save then Done.
The next time the trigger fires, and it detects a source change, the CI build will take place. It will be identified as a "Scheduled" build on the Dashboard.
Note that if you are not seeing scheduled builds, it is most likely because no changes have been made to the source code. To see a scheduled build, you need commit a source change and wait for the CI build to occur.
See Set Up Notifications.
You can set up AnthillPro to notify users when a build completes, to provide developers with more feedback on the CI build. To do this, each workflow is assigned what is called a notification scheme in AnthillPro. The notification scheme defines:
Who is notified. For example, you can choose to notify just the developers who committed changes to the build, every user that works with the project, every AnthillPro user, etc.
When a notification is sent. AnthillPro can be configured to send a message when a workflow status changes (i.e., the build breaks), when any workflow completes regardless if it fails or not, etc.
How the notification is sent. Standard notifications are sent either by e-mail or instant message.
AnthillPro ships with a Default CI Notification Scheme (in some versions it is simply called Default Notification Scheme) that sends an e-mail to all repository committers upon a change in status to a CI workflow. Since you are just getting started, it will be easiest to use this notification scheme.
Since you will be setting up AnthillPro to send e-mails, you will need to do some basic configuration within AnthillPro and on your e-mail server. To begin sending notifications:
Follow the instructions given in the Configure Mail Server section and then go to the next item.
Go to Administration and select the workflow you created in the Create a New Workflow section.
On the workflow Main page, verify that you are using the Default CI Notification Scheme. If so, you are done. If not, go to the next item.
If the workflow is not using the Default CI Notification Scheme, click the Edit icon (the pencil on the left).
Select Default CI Notification Scheme from the Notification Scheme menu then click Save.
The next time a build is completed, committers to this project will receive an e-mail notification.
With AnthillPro automatically kicking off builds and sending out notifications, including a unit test suite that runs every time you run a build will help identify any decrease in code quality. If you use CppUnit, JUnit, or NUnit, AnthillPro has a built-in integration that will parse and then store your test results, making them available on the Dashboard. This will enable you to use AnthillPro to view results, track changes over time, and even have AnthillPro e-mail the results.
To integrate unit testing with your CI build, select the type of unit test you use from the list below and follow the instructions for adding them to your build process.
When done, you can consider some Next Steps.
Switch to a repository trigger. AnthillPro can be configured to use a repository trigger in conjunction with a SCM system. With a repository commit trigger in place, a build is kicked off every time changes are committed to the SCM. See Use Agent Filters and Quiet Periods and Workflow Triggers and Scheduled Builds.
Configure custom notifications. Set up custom notifications with AnthillPro based on a number of different criteria, including e-mailing test results. See Managing Notifications.
Setting up a deployment workflow. Now that you have success with the basic CI build, you can turn your attention to the "output" phase of your build process: setting up an automated deployment process. See Setting Up a Deployment.