Emerging Fields for Continuous Integration

Continuous Integration (CI) is one of the fastest changing fields in enterprise programming. Here we look at what is changing, and who is winning in the world of continuous integration and continuous delivery.

Continuous Integration (CI) has become well-established for web application development in traditional languages such as Java. The major CI systems including Jenkins and Hudson with all their attendant tooling are also highly developed and feature a great deal of support for the development community. However, there are a couple of fields that are still trying to catch up with the CI trend. The recent acceleration of mobile application development and the growing popularity of JavaScript for both front-end and back-end programming have left CI tooling scrambling to keep up.

Mobile development increases the complexity of integration

A development team can currently use Jenkins, TFH or other platforms to do automated builds and testing for mobile. There are also tools available to help users write scripts in Calabash and 'device clouds' for testing on simulated hardware that can all be integrated with CI. However, what these tools can’t do is identify, predict or prevent all the potential problems that will arise and throw a wrench in the works. On a practical level, there’s still a lot of hands-on work in mobile development.

Eran Yaniv from Perfecto Mobile agreed that CI as a process has a long way to go to make the developer experience seamless and productive. 'The main difference is the nature of mobile. You have many surprises. There can be corruption of your mobile device, there can be loss of signal, battery draining, and so on. When you are doing Continuous Integration testing for a traditional environment, you start the Jenkins ‘job’, you have a flow end to end, you come in the next morning and read the emailed report, and you move forward.'

The situation is a lot less rosy for mobile application development. 'In mobile, the continuous integration needs to be mature enough to be considered unattended CI. Right now, it’s more difficult because there are more elements that can get in your way. It could be operating system bugs, software bugs, hardware bugs, hardware limitations or issues you don’t expect. When you come in the next morning to read the report, you may not find what you expect, and you have lost that time.' When this happens, Continuous Integration looks a lot more like 'Stop and Start' integration.

JavaScript is merging slowly into the CI workflow

JavaScript is taking on a new role as a major programming language. It’s no longer only a tool used to run simple scripts on the front end. From Node.js on the backend to heavy lifting on the client side, JS is becoming an essential part of the core of today’s web and mobile applications. Solutions such as Angular and Ember are well on their way to becoming full-fledged frameworks for JavaScript programming. Even as these frameworks streamline and simplify JS development, they still can’t match the breadth of functionality or the speed of the ecosystem surrounding traditional programming languages.

Mike Hostetler at Append To said he sees substantial progress in making testing work for JS in CI. 'Testing especially is growing in importance. There are three tools we recommend. QUnit is the most popular. There’s also Jasmine and Mocha. You can’t go wrong with any of the three. All three plug into CI systems that will do the type of Continuous Integration and Continuous Deployment you’re used to in a more statically typed language.' The expansion of JS into the backend is also having a positive impact on the evolution of JS and CI. According to Mike, the explosion of Node.js tooling in particular is beginning to carry over into the front end, adding to the options available for JS development.

At this point, the lack of organization is proving to be the biggest challenge. O'Reilly Media Senior Editor and Fluent co-chair, Simon St. Laurent, described his view on the current state of CI as it relates to JS: 'I feel like Continuous Integration is just getting started and is coming kind of late to JavaScript.  People have been using Jenkins and Travis to do JavaScript stuff as part of a larger project and there’s been a set of tools emerging on the JS side like Grunt, YAML and Bower. They aren’t CI tools by themselves, but you’re seeing the building blocks come together. We’re learning. We have a lot of the key pieces; we just have to adapt those pieces to the environments and expectations of JavaScript folks.'

While Continuous Integration roadblocks for both JavaScript and mobile are likely to be overcome in the next few years, there will doubtless be new disruptive technologies and languages coming online to take their place. In any event, the CI ecosystem itself will always be subject to continuous change.

Dig Deeper on Java application testing

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Interesting how the landscape has changed in the last two years. CI/CD with JavaScript-based applications is now a full-blown reality.