Skip to end of metadata
Go to start of metadata

 

In This Chapter

Continuous Builds and Continuous Integration

Continuous integration and continuous builds are mainstay features of modern software factories.
Continuous integration is the practice of development changes being tested, built, and reported in small increments during the development process. Continuous build is an extension of this practice to provide a newly tested build of the software every time a developer commits changes.

Principles of Continuous Integration

Understanding continuous integration principles, in conjunction with continuous build tools, helps drive an efficient software factory, and by extension, efficient software development. These principles include:

  • A unified code repository -- the team must have access to shared code (team sharing, Git/SVN/...)
  • Frequent commits -- every developer commits frequently to the repository so changes are incremental
  • Commits are built -- when the code is committed by a developer, the software is built to show it is functional
  • Builds are automatically tested -- When the code is built, unit tests are performed (this can be extended with code coverage, code analysis, end-to-end testing, performance testing, ...). If errors are found in a unit test, the developer can correct those errors immediately
  • Results are available to everyone -- if a build breaks, everyone can see where the issue lies and what needs to be done to fix it
  • Successful builds are deployed immediately (automated deployment) -- this ensures that the latest software is available to everyone in the team (product owners, testers)

Developer's Role

With these principles in mind, the developer's role in the continuous integration process can be summarized as follows. Developers should:

  • Commit their code frequently.
  • Review the results of unit testing, and if unit testing fails on their commit, fix the issue as soon as possible.
  • Update their workspaces frequently to get changes from others in the team.
  • Write test scripts for unit testing (unless this is the responsibility of the testing team).

Software Tools

Software tools can help with managing and practising continuous integration; in fact, continuous builds are normally vastly software driven. Software considerations include:

  • Repository software - software to manage the code base (Git/SVN)
  • Build software -- software to actually build and run tests (ANT)
  • Communication software -- how to communicate information among the team members.
  • Deployment software -- in our case, Servoy Application Server & Apache Tomcat.
  • Continuous build software -- software to manage the continuous build process and make sure each step is occurring.

Continuous Build Software

There are many different choices for continuous build software available, such as Jenkins, CruiseControl, Continuum, Bamboo, and others.

This tutorial shows how to use Jenkins for the task at hand.

Using Continuous Build Software with Servoy

In regards to Servoy projects, Jenkins is used to fill the following needs in our software factory

  • Checking the Git repository for new code changes (or getting notified that new code changes are available) and building the software when the SVN is committed (exporting the solutions in different needed formats).
  • Running the unit tests, end-to-end tests.
  • Providing a new build of the software for testing and availability. (deploy a war containing the new version of the solution to a running Tomcat server)

Jenkins is very flexible in how they can be configured and the methods and strategies can differ depending on a variety of factors. In the case of using it with Servoy, we also utilize it's ability to run ANT scripts. Through these ANT scripts, tools provided by Servoy Developer export the solution into  .servoy (for unit tests) and .war (for deployment and mobile unit tests) formats, then ant runs the unit test tools provided by Servoy: a smart client based test client that will import the solution into a repository and run unit tests on it and a mobile client based test client that will import the service solution and deploy the mobile test war and run unit tests on it . Finally, if unit tests are passed, end-to-end tests are run (using a war deployment of the solutions and ngclient + protractor and/or selenium runner for java) and then a war is deployed to a manual test Tomcat server.

Rather than explain everything in detail that can be done with Jenkins and a Servoy project, it is more beneficial to provide an example of Jenkins and the supporting applications configured for a continuous build server.

The Servoy Software Factory Example using Jenkins section will cover in detail setting up a continuous build server for some sample Servoy solutions.

 

  • No labels