Continuous delivery is the implementation of the developing, compiling, deploying, testing, and releasing software in an automated fashion with an aim to compress the time to release. Continuous delivery or continuous integration aims to have a quick and automated feedback to evaluate and understand the production readiness of a release candidate. This philosophy is embraced by Devops which defined as the software development method that emphasises on communication and tight collaboration between all the parties involved in the software development lifecycle.
As Agile gains momentum it is very important to note that Agile fails without Continuous Integration. If you do not have automated test check the health of your build or for your regression its almost impossible that QA would be able to test within the same sprint or run as fast as they need to. As an agile team one should aspire to move to the better edge of the Continuous integration spectrum.
Evaluating where your teams stands is can be done by asking yourself the questions like- How much manual work does your team need to do to get a product out ? How much time is spent on building the feature vs everything else ? An adoption of agile without the right tools in place is scary and a half hearted effort.
Think about a a garage single developer he could probably get get a small feature out in an hour or two. For a Scrum team with a 4 weeks iteration how long would it take your team. The important thing is to make sure your code is deployable as soon as you have it tested. The change management process should be in relevance with how heavy your changes are. Suppose you have a kanban team releasing everyday or couple of times a day and have a heavy change management process it would bring you process to a crawl. At the same time if you team is handling multiple releases in a day you need to have effective rollback process and emergency release process that deal with frequent changes and A/B testing frameworks.
The speed and accuracy of your testing is vital as an SDET you get builds at the very end of the sprint you most likely have written you test cases while the development was progressing. But testing the feature aside running you Regression needs to be automated and should not take too long. The longer it takes to test your release feature and do the regression the more time to deploy. A constant effort is to have your QA tests greenlit so that you do not have many failures you need to look at when you are running your regression.
Adding code coverage tools also help in understand your test case coverage and your not deploying anything that you have not tested.
As an agile team it is good to revisit your process every once in a while either during a retrospective or in solitude. Evaluating bottlenecks and where you can improve the efficiency of your team in essential to continuous improvement.