Servage Magazine

Information about YOUR hosting company – where we give you a clear picture of what we think and do!

Automating testing with continuous integration

Friday, December 16th, 2016 by Servage

Continous-IntegrationIf you are writing tests for your application or your application must be prepared for release each time a new version is created, you should be using continuous integration (CI). It allows you to automate both of these processes by triggering them whenever you want, such as when you push a commit to a Git repository. Continuous integration can save you a lot of development time, and this is how you can get started.

Why Continuous Integration?

If your application is still in development, probably the biggest advantage in CI is the ability to automatically run tests for new features. You can also use it to build your application from source code into an executable application. If your product has not been released yet, you can use this feature to distribute your product to testers. On the other hand, if your application is already released, this can be useful to distribute your application to end users.

When you download a program, you can often notice the word “latest” in the download link. In that case the executable program has likely been built using an automated build system.

How to get started?

To start using continuous integration in your own project, you have to choose from multiple CI products. Popular ones include Jenkins, Travis CI, TeamCity, Bamboo and CircleCI. If you are looking for a free and self-hosted solution to have complete control over your build and testing server, Jenkins is a good choice. If you would like the setup process to be as simple as possible, have a look at Travis.

Regardless of what product you choose, the setup process is mostly the same. The first step is to create a new project. A project is usually a repository in your version control system. While creating a new project, you can give the URL to your repository along with a way to authenticate against the repository if it is not a public repository. You can authenticate using a password, SSH key, deploy key and by some other means depending on your CI software.

Another thing you have to configure during the setup process is build triggers. A build trigger is an action that triggers the building and testing process. An example build trigger is when you push a change to your repository. If you use GitHub, you can create a webhook in the settings area of your repository. The hook will send a notification to your CI server telling something has been pushed to your repository, and this will trigger the build process. There are other types of build triggers as well, such as a specific time interval or polling a repository for changes.

The last step is to tell your CI server what to do when a build takes place. With Jenkins and many others, you can give a list of commands that will be executed in a directory where the latest source code has been downloaded to. You can use these commands to run tests, build an executable and even upload the executable to a CDN server via FTP for easy distribution.

Automating testing with continuous integration, 3.7 out of 5 based on 3 ratings
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet (leave a comment)

You are welcome to initiate a conversation about this blog entry.

Leave a comment

You must be logged in to post a comment.