Scrum and CI/CD

Reference: Continuous Delivery for Java Apps by Jorge Acetozi, published by Leanpub on 7 February 2018.

Scrum and Continuous Integration

Continuous Integration (CI) is a development practise from Extreme Programming that requires developers to integrate code into a mainline as often as possible, at least once a day, where each check-in is verified by an automated build that compiles the code and runs the suite of automated tests against it, allowing teams to detect problems early.

To implement continuous integration, the whole team must understand that:

  • Tasks should be small. They have to last no more than a day to be coded (including automated tests) and integrated to the mainline. This is required for continuous integration.

  • Continuous Integration is a requirement before we can do Continuous Delivery.

Deployed vs Released

It is important to understand the differences between these terms:

  • Deployed: The technical task of introducing a product into a chosen environment such as testing, staging, production, etc.

  • Released: A business term that refers to the functionality made available to the end user.

Note: To deploy does not necessarily mean that the product has been released. Code can be deployed to production but remain inactive to the end user.

Scrum and Continuous Deployment

  • When Continuous Integration is done daily in an automated, safe and fast way to deploy code to production, the decision to release features does not reside with the IT team anymore. Instead it is the business users that decide if it should be enabled in production.

  • This practise of performing Continuous Integration at least once a day and automating the deployment to production is called Continuous Deployment.

  • In big software projects with mature and robust completely CI/CD mechanisms in place, this process is usually occurs multiple times a day.

Automated Testing

  • You cannot have Continuous Integration if you do not have Automated Testing.

  • Whenever code has been committed after the developer has completed unit testing and functional testing, once he commits the code, automated test scripts must perform

    • automated regression testing to verify that existing functionality is not affected

    • automated function testing on the new features to ensure it works as expected

  • These automated tests must pass before the code can proceed to Continuous Integration and must kick in automatically once code has been committed.

  • The development team has to learn about automated testing and coding it in for every new feature, re-factoring or bug fixes. Otherwise, they would be delivering code to production without knowing if it works or not.

  • This is required for new features, configuration changes, bug fixes and such to go into production safely and quickly in a sustainable way.