At Calavista, we were interested in DevSecOps before there was an overall term for these best practices in software development. We were founded on concepts such as Continuous Integration and Continuous Delivery, pioneering Agile development. Since the early 2000s, the software development and DevSecOps scene has changed dramatically, exploding with new technology to help streamline […]
At Calavista, we were doing DevOps before it had a buzz-word title. Likewise, we’ve been doing DevSecOps for quite some time, and it’s about time we start calling it what it is.
Our previous blogs have defined DevOps as a collaborative culture with its own defined practices, ideas, tools, technology, processes, and metrics. Integrating some of these elements into your workflow can help streamline and improve your development process.
DevOps has made it possible for organizations to develop and release stable applications faster than ever. However, and organization with a proper DevOps pipeline should always include Continuous Monitoring through the development lifecycle.
Test Driven Development (TDD) is a development practice where developers author code by first describing the intended functionality in small, automated tests, then writing the necessary code to make that test pass.
In the last decade, we have seen significant shifts in software development operations. One of these shifts is the evolution of DevOps, which came into play in 2008/9.
In my last blog, I talked about how we estimate new projects, and I included the offhand comment that Data Migration is always harder than you think it will be. The purpose of this blog is to provide a few examples of why I find this to be the case.
In my last two blogs, I went over specifics of Continuous Deployment and gave some examples of how you can enforce quality controls even though you are releasing at breakneck speeds. To finish off my series, we will dive into Dark Launches and Feature Toggling.
In Part 1, we talked through some of the misconceptions of Continuous Deployment (CD) and how it does not create a “Wild West” release approach. This time, I want to cover three major flows or processes (using GitHub as an example) that can be implemented to enable delivery of stable, high-quality features.
Often, Continuous Deployment is considered a step too far for most development organizations. Many people fear that it removes any gates or approval process and put the release mechanism solely in the development team’s hands. That is incorrect. Continuous Deployment can actually increase controls and provide better code!