Enterprise CI/CD Best Practices - Part 3
This is the third and last part in our “Enterprise CI/CD best practices” series. See also part 1 and part 2 for the previous best practices. You can also download all 3 parts in a PDF ebook.
The latest News and Information on Continuous Integration and Development, and related technologies.
This is the third and last part in our “Enterprise CI/CD best practices” series. See also part 1 and part 2 for the previous best practices. You can also download all 3 parts in a PDF ebook.
DevOps, DevSecOps and CI/CD are synonymous with one word - automation. Automating their workflows gives developers the ability to deliver consistency, time savings, and useful insights into their software development life cycle (SDLC). But automation is only as efficient as your weakest link or most cumbersome bottleneck, which can sometimes be security testing. Security testing has traditionally been carried out either manually or quite late in the process.
For the past two and a half years as a Solutions Engineer at CircleCI, I’ve had the distinct pleasure of working with some of CircleCI’s largest customers to help them instill healthy CI/CD practices into their development processes. Leading-edge organizations are trying to make sure that their applications are scalable, reliable, and secure. Shipping products to users quickly and reliably is imperative to gaining a competitive edge.
In early 2020, threat actors breached the build systems of Solarwinds and used this access to add malicious code into one of SolarWinds products. The product, called “Orion”, is very widely used and deployed by tens of thousands of companies, including many Fortune 500 companies.
Software delivery on a team of 2 people is vastly different from software delivery on a team of 200. Over the growth of a startup, processes and tool choices will evolve naturally - but either optimizing too early or letting them evolve without a picture of where you’re headed can cost you in time and agility later. That’s why I want to talk to you about how to evolve your delivery process with purpose.
As a developer I couldn’t imagine working without one of these three things. For projects on GitHub the built-in actions should do the latter job fine in most cases. But as everything else they have limits. The more PRs, the more different tests per pull request and the longer those tests run, the longer different PRs have to wait for each other for the continuous integration to run.