CI/CD and the Agile Principles

CI/CD and the Agile Principles

What does our Continuous Integration and Continuous Delivery pipeline have to do with being Agile? And what’s in it for you?

Join us in exploring the answers alongside the 12 Agile Principles:

1. Our highest priority is to satisfy the user through early and continuous delivery of valuable software

Off to a great start: it’s all in the name! Continuous Integration & Continuous Delivery pipeline.

Any released changes to new or existing connectors (also known as “protocols” or “drivers”) are flagged to the user on their DataMiner system allowing them to immediately deploy the changes on their live system.

Also new and updated items are validated and made available for immediate use via the Catalog!

Steps of the CI/CD pipeline

Even a beta version of a connector, with the purpose of gathering feedback early from real (staging) environments, is possible with CI/CD: the pipeline generates artifacts with a unique ID for these intermediate builds.

2. Welcome changing requirements, even late in development. Agile processes harness change for the user’s competitive advantage.

Implementing changes is our core business and CI/CD lets us make those changes without any fuss. You can request and make as many changes as you want, whenever you want. Changes are no longer a costly endeavor.

Any change gets pushed through the CI/CD pipeline, which will then validate it. This allows us to be confident that the change works as expected and continue to make changes as often as desired.

For example, the pipeline executes the DIS validator. In addition, the Major Change Checker is also run to detect any changes that implicate a major range change.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

CI/CD doesn’t deal in weeks… *smirk*. Delivering working software becomes a matter of minutes.

4. Business people and developers must work together daily throughout the project.

We will open up our CI/CD for collaboration between users and Skyline experts. Working together on connectors, scripts, dashboards, etc. As if they were one team creating value.

Users will be able to push changes directly to staging or even production systems through the cloud API with the support of CI/CD.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

We know there are already a lot of motivated individuals out there, just look at the Dojo community! CI/CD is the environment that allows you to confidently experiment with your own drivers, scripts and more.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

*beep* *beep* *boop*

This has to be the one principle where CI/CD has nothing to offer. CI/CD simply isn’t sentient enough yet to make any meaningful face-to-face conversations. Skyline’s AI team has its work still cut out here 🙂

However, note that the CI/CD pipeline can be a trigger for face-to-face conversations. For example, when a build fails, the person that triggered the build can contact someone else to get input.

7. Working software is the primary measure of progress.

The software does not pass through the CI/CD pipeline? Then it’s not working software and no progress has been made. End of story.

The pipeline applies the fail-fast principle: if a previous stage fails, then the next stages in the pipeline are no longer executed. No resources are wasted on anything that is not considered working software. This ensures that every increment that does get through the pipeline is in fact working software and progress can be measured.

In the example below, the Quality Gate stage of the pipeline failed, skipping all subsequent stages and marking the pipeline run as failed.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

CI/CD makes the development iteration simpler and more transparent. A lot fewer manual checks and registrations need to be done by the developer since CI/CD automates these.

Let the CI/CD pipeline reassure you of the code excellence or guide you in troubleshooting when it fails. Because creating more breathing room in the testing department means that the developers can focus on what they really love to do: developing. Moreover, this way they can maintain a constant pace.

9. Continuous attention to technical excellence and good design enhances agility.

The main purpose of CI/CD: taking care of the technical excellence of any software going through the pipeline so that we increase our ability to innovate, prevent technical debt and enhance our agility.

The stages where CI/CD executes the DIS validator or the SonarQube code analysis are some fine examples of how attention to technical excellence is enforced.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

Stop wasting time right now!

You no longer need to spend time on an extensive investigation, doing handover after handover. Instead, share the link to the pipeline. Then you quickly get a complete overview, and you also see at which step the change failed validation and why.

Every increment of your connector, script, Visio, etc. can be assessed by CI/CD. This allows you to catch mistakes early on and adapt the next increment accordingly.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Autonomous and self-organizing teams are essential to enable fast decision-making tailored to specific needs and variable environments. And that’s why users are (and need to be!) free to decide upon the architecture of their solution.

The CI/CD pipeline will support package chains allowing you to define, create, and deploy packages. These packages will contain all necessary components of your solution corresponding to your architecture.

Moreover, you can configure your package pipeline so that it is retriggered as soon as one of its constituents (e.g. a connector) has been updated. For example, when a connector that is used in your package has been updated by another team, the package pipeline will be re-executed ensuring this updated connector is still compatible with your package.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

CI/CD pipeline makes issues transparent, which is required to be able to inspect and adapt accordingly.

For example, the DIS validator stage executes the DIS validator and generates artifacts listing all detected issues for reference.

The SonarQube stage executes code analysis and publishes the results on SonarQube.

Leave a Reply