Progress announced the latest release of Progress Flowmon.
CI/CD pipelines enable your teams to deliver higher quality software, quickly and efficiently. By combining the practices of continuous integration and either continuous delivery or continuous deployment, dev teams can spend more time on projects and less time on manual tasks.
However, CI/CD pipelines are still evolving. As we incorporate security measures, become more deployment-centric, and move towards full automation, there is a lot to consider when building your own CI/CD pipeline.
I asked several speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors to weigh in on how they think CI/CD pipelines are evolving. Here's what they had to say in Part 2 of this two-part series:
Start with: 8 Ways CI/CD Pipelines Are Evolving - Part 1
Speaker, Ravi Lachhman
CI/CD pipeline is becoming more deployment-centric; potentially, any change should be deployed as software design is becoming more incremental, pipelines are the core conduit from idea to the end-users e.g., production. With the rise in container orchestrators, the art of the possible such as the pipelines enforcing state/conformance of changes in a declarative fashion is now possible.
Speaker, Anders Wallgren
VP of Technology Strategy, CloudBees
Increasingly, software pipeline platforms support defining pipelines-as-code using domain-specific languages, in fact, it's pretty much table stakes these days. Being able to define pipelines as code allows for better documentation, testing and change management of pipelines. It also allows them to be more easily integrated into GitOps-style workflows.
Technical Lead, Novetta
CI/CD pipelines are the crown jewels associated with good DevOps and Agile practices. Since these practices advocate functional delivery and self-organizing teams, each team may have its own CI/CD solution based on its particular problem. CI/CD options are cooking, not baking; ingredients have to be included, but the measurements are up to the chef to adjust based on how a project responds, matching the taste to the customer.
One of the more important parts of the CI/CD pipeline is that each team should have its own environment, or set of environments to work in. Virtual environments allow mirroring between functionalities. The more each environment can mirror the ultimate delivery environment, the more successful the pipeline is likely to be.
CEO and Co-founder, DeployHub
CI/CD is moving from old ways of imperative practices to new thinking of declarative models. Event- based CI/CD will be the future of continuous delivery.
DevOps Evangelist, Zensar Technologies
Observability. It's one thing to have automated build and deployments, it's totally another to analyse the patterns of usage over time and then derive conclusions and take proactive actions. For example, for one customer, the analysis told us that while the frond-end builds were good, a couple of modules of the Java application typically had a lot more build breaks, and they were coming from a new team. Further digging identified a training need for the team.
IT Development Manager, TD
CI/CD pipelines are evolving with full automation (subject to the maturity of the company, team). From the time code is checked-in with all security scans in place (code smells, vulnerabilities, etc.), an artifact is created and deployed successfully. The more shift left security is included in this automation, the better it is for the company and its assets.
Lead Systems Engineer, EPAM Systems
CI/CD has become the backbone of DevOps-driven organizations. CI/CD is not only the platform to deliver software to environments but to deliver solutions end-to-end. Infrastructure as code, security as code (shift left), etc., are part of CI/CD now and will be incorporated in autonomic processes more and more.
Principal Engineer, Catapult CX
What's interesting is that developers no longer have to own and set up the necessary infrastructure for CI/CD. There's a shift away from building the pipeline from scratch yourself, towards using a pipeline through a cloud provider such as GitLab, Bitbucket or Github. The growing number of tools and integrations with third-party services also changes the process involved. For example, in the past, at the end of a build step, we would have to collect the results and store the data ourselves — now though, there are third-party services that keep records of it for us. There are, however, some limitations to this. While it certainly helps speed up the process, I worry sometimes that there is too much focus on the pipelines shipping code and the operations side of DevOps gets neglected. To overcome this, at Catapult CX, we find it helpful to have service dashboards that include real-time stats from the pipeline alongside service level metrics, closing the feedback loop from an operations standpoint.