Increasing efficiency with Continuous Integration

Cloud CRM solutions have long been lauded for the speed at which IT solutions can be developed, tested and deployed. However, if the sufficient control and governance mechanisms are not wrapped around development and deployment processes, these technological advantages often place natural pressures on solution quality and sustainability especially in highly regulated industries.

Where appropriate, we propose a Continuous Integration (CI) approach to development.

CICI is structured to deliver the necessary governance and control over system development, testing and deployment, infusing the best of traditional waterfall controls into the Agile approach.

What is Continuous Integration?

CI is a development practice that requires developers to integrate code into a shared repository as frequently as possible. We set the minimum frequency at once per day. Through a process of automated deployment into testing environments, CI reduces the time lag between development completion and delivery to testers whilst ensuring sustainable solution consistency.

How do we do it?

  • controlled code repository.png

    Maintain a controlled code repository

The starting point is to create a single cloud- based code repository for development, (this is essential for supporting virtual development teams).  Developers commit their components as synchronously as possible to the same source folder(s) for early conflict detection, absolving the need for individual working environments.

  • Automate the build

A cloud-based build automation tool is linked to the repository, which results in every successful change to the source repository being built to the designated destination environment. All changes are version controlled and the metadata from different versions can be forensically compared. Development progress is transparent and new functionality can be tested at any point in time. A good build tool will monitor the outputs of build executions providing stakeholders instant feedback on whether a given build is ‘broken’ or ‘stable’ (i.e. eligible for automated deployment). In this way, the build is self-testing.

  • Partition the build as required to support continuous sprint development

Environment challenges often arise when projects are keen to run post unit testing phases such (e.g. SAT, UAT) for a given release concurrently with sprints for a future release. The need for separate environments and multiple code repositories is clear.

To alleviate these challenges, we partition the repository and create separate branches. This allows us to manageably segregate code associated with the earlier release from the latest development.

 

  • Safely manage change through solution traceability

Accompanying each delivered requirement we would:

  • solution traceabilityDocument a comprehensive design specification covering the main components built to deliver the requirement
  • Reference an automated build version number proving that the relevant components have been ‘committed’ to the repository
  • Automatically log the date and time at which the peer and technical reviews took place along with the identities of the reviewers
  • Document the release instructions and validation steps to be received by the release team. Release responsibility is consciously segregated from development. Independence from the developments allows the release team to ensure best practice development principles are sustained.

Why do we do it?

  • Accommodate change in a controlled manner

This is the primary purpose of CI. Change is inevitable and welcomed, but the challenge is to accommodate change without sacrificing overall environment and build quality. The costs and unquantifiable risks associated with unmanaged development and deployment far outweigh the costs associated with the setup and maintenance of this approach.

  • Infuse the best of both Waterfall into Agile

It is a commonly held misconception that Agile development dilutes project control and governance. By following a sequentially structured, repeatable and automated development process, it is possible to achieve the traditional benefits of the Waterfall methodology in an Agile environment.

  • Satisfy compliance requirements

We believe that many cloud implementations would benefit from CloudShift CI, however, for many of our customers, this quality focussed approach is a ‘must have’ as we support them in their responsibility to remain compliant in an ever more complex regulatory environment.

When it comes to implementing Salesforce then improving the efficiency of how systems are developed, tested and deployed is crucial. Here at CloudShift we’re experts in this through our ‘RapidShift’ programme. Please drop us a line, we would love to hear from you.

 

Posted in: