Automated System Used for Continuous Integration Build Code Create Packages and Run Code

Summary:

How often have you or one of your teammates checked the source code into the code library which then instantly triggered an automated build?  How many times did this instant build succeed? Do you have an automated build and release system that ensures your software is built in the same way each and every time? Are deployments to staging environments entirely automated and executed with a single click? While reviewing a defect in a production release, are you able to backtrack through the source code changes and identify the root cause of failure? If the last good checkin happened a few days ago, identification of this root cause of failure would become even more difficult. Seasoned CM practitioners advise that you perform a daily build to avoid such integration issues. What an irony it is that only a few projects take advantage of this simple, yet powerful technique known as Continuous Integration (CI).

Read on if you would like to explore the use of continuous integration, build and automated deployment. An automated build framework not only helps in solving integration issues early, but also assists by building and deploying the complex products quickly and further helps in ensuring that the build processes are transparent, auditable and repeatable.

Continuous Integration - A step towards quality
In the words of Martin Fowler, Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

While a large number of teams claim that they have continuous integration framework in place but in reality most of them do not. Many teams do not write unit tests or they do not have automated deployment mechanism in place. Eventually, they end up doing just continuous compilation which is of little help. Most of these teams do have build automation tools, but they do not use these tools to their real potential. It is like having good paint and brush tools, but not knowing how to draw a good picture.

Types of Builds in Continuous integration
How does one get started with continuous integration? There is no fixed start-to-finish recipe, but as a first step, it would be good to setup a single code library so that whole system can be built with a single command. The next step would be the identification of build types which should be configured. Pre-release builds (hourly/nightly) help developers to improve the quality of the source code and release builds help in automating the release process. A typical build cycle should have the following four types of automated builds.

Hourly build , configured to check the sanity of source code, should at a minimum compile the source code and execute the unit test cases. Hourly builds are a good friend of developers and provide them immediate feedback if something is broken. Some Teams prefer to configure automated code reviews within the hourly build plan as well.

Nightly build (or daily build) is another automated build which takes place when no one is in the office. Nightly builds are configured to test the software in a test suite. Test results from nightly builds provide developers the feedback on how their test suite is progressing. The following activities can be part of a nightly build

• Compilation & execution of unit tests
• Automated code review
• Creation of code coverage report
• Creation of design quality matrix for each source code package, dependency analysis and cyclomatic complexity
• HTML-based cross reference of entire source code
• Automated deployment in a staging environment
• Execution of automated functional and regression test cases
• Notification to stakeholders about build outcome by email and/or on central build dashboard

Release build is configured to make a release to QA. It is always recommended to automate the steps of a release build. The standard build steps would include:

• Tagging the source code
• Compilation and creation of the build package
• Creation of installers
• Moving deliverables to release area
• Creation of release notes and publishing the same on the project dashboard
• Automated deployment in testing environment
• Execution of automated functional, regression, performance and acceptance test cases and creation of test report
• Publishing the build artifacts
• Notification to stakeholders about build outcome by email and on central build dashboard

Promotion Build is configured to move the tested build artifact from one level to another (e.g. from QA to Release). The steps would usually include using the artifacts of original build or re-producing the artifact from exactly the same source code, tagging the tested source code, sending notification, and might optionally include auto deployment and execution of a few more test cases.

Need of Application Lifecycle Management (ALM) Infrastructure
Continuous integration is a wonderful practice, but how does one review a defect coming from a production release? After a few months of the application release being in production, it would not be easy to identify the root cause of failure in the source code. You need to find out the build in which the relevant feature was delivered and also its corresponding source code. Most of today's defect tracking systems facilitate this information by providing interfaces which interact with version control system and the build server. In summary, this would require an application lifecycle management infrastructure. An integrated application lifecycle management (ALM) infrastructure would consist of an issue tracking system, a version control system and a build server. The integration among ALM components provides the ability to compare releases by issue or by defect.

Enterprise Build Automation
Most enterprises which claim to practice continuous integration would have few individual project teams managing automated builds and releases with the help of an open source or home grown tool. These build environments are typically isolated and not accessible to other projects. Moreover, their build processes, too, would differ from project-to-project and would rarely meet the standards set by the organization.

The next step towards innovation would be to build an enterprise-level continuous integration framework which would automate the build, test and deployment processes for the entire organization. This would require a central build server which would be a process driven component where software are built, integrated and tested. An enterprise level build automation system simplifies the administration of build processes, systematically eliminates build failures, and delivers maximum execution speed for all builds.

An advanced enterprise level build automation system' capability would include cross-platform builds, parallel builds, easy troubleshooting and administration of build environment. Moreover, enterprise level continuous integration would give organizations the power to enforce best practices throughout the organization and would make build processes transparent, auditable and repeatable.

How can we ignore the need for a centralized dashboard view which helps in clarifying the issues by providing all the necessary information together? Dashboards which can be customized depending on the nature of the project would be most helpful. Dashboard items might include:

• Build progress matrix (e.g. Gantt Chart)
• Passed vs. Failed test cases for each build
• Summary of the features added/modified/deleted with each new build
• Code coverage statistics - Identifies the source code not covered by the test cases.
• Code review statistics - number of Errors/warnings with each build
• Percentage of successful builds over a period of time
• Time to fix the build

A nice to have feature of build dashboard would be the ability to compare the statistics across build plans. For example, a single report comparing the code coverage statistics of all projects would help in identifying those projects which ignore the importance of writing unit test cases.

Summary
It is my firm belief that once you have worked on a project having continuous integration, you would not want to work on a project having no CI. If you are not using Continuous Integration I would advise you to give it a try. If you are, maybe there are some ideas in this article that can help you do it more effectively. Initially it would require some effort but once you are done with the initial scripting and scheduling the builds you would it extremely helpful and fairly easy to maintain.

References:
http://martinfowler.com/articles/continuousIntegration.html - Continuous Integration, by Martin Fowler
CM: THE NEXT GENERATION - Project vs Product SCM Using Dashboards, by Joe Farah
http://www.viewtier.com/support/articles/build_server_capacity_planning.htm - Capacity Planning for Build and Release Management Servers, by Viewtier Systems

reckfectauz.blogspot.com

Source: https://www.cmcrossroads.com/article/continuous-integration-and-enterprise-build-automation

Bagikan Artikel ini