Many IT groups and organizations already have some sort of continuous integration or continuous delivery in place. If they don't they are probably in the process of wanting to implement some portion of CI/CD. Each IT organization has their own culture and a particular way in which they develop, test and implement software. There is not one particular way that they should implement CI/CD processes, procedures or pipelines but there are some principles they should keep in mind to find the ultimate CI/CD "sweet spot".

What is the goal?

The goal of any for-profit organization is to make money. In the case of adding CI/CD processes and procedures that translates to adding value. According to the dictionary, a "sweet spot" is "an optimum point or combination of factors or qualities". When setting out to provide CI/CD to a given product or piece of software you need to continually keep an eye to what adds value and what does not.

How do you decide which things add value?

You need to find the things that allow all of the people contributing to the product to either do more with less or go faster. Developers want to go faster and not make mistakes. Although they may exist, I don't think I have ever met a developer that messed up on purpose. If a mistake is made in a piece of code that is most likely because they either didn't know a better way to do it (and probably copy/pasted it) or had no idea it was going to break something else. Most organizations currently have some form of static analysis tools and also require or enforce some level of unit testing as well as executing automated QA tests. This is a great place to start to add value but you shouldn't just add these checks to a pipeline without a few considerations.

Can the same check be executed locally?

Steps need to be able to also be ran on the developer's local environment to let them know about violations before those violations are found when checked in the pipeline. A step in the pipeline should not be introduced unless the same check can be performed and verified locally.

Should a failure during a particular check block the pipeline?

Most of the time when introducing static analysis or unit test coverage to an existing codebase there are going to be a fair amount of failures or low coverage. If this is the case it is good to go ahead and run the check and also report on the results but do not fail the pipeline yet. That is a goal you can work toward as code becomes more stable and developers can fix the things that are found in the report.

Does the team find the rules valuable?

As the team progresses through using a particular set of rules for either static analysis or coverage it is good practice to routinely take a look at the violations and determine how valuable the different rules are to enforce.

Are automated tests really finding defects?

The execution of automated tests needs to be repeatable and reliable. If they fail for reasons other than a code problem or a difference in what the test is expecting then they need refactored and not run in the CI/CD pipeline. If failures are disregarded because of a volatile environment or data issues then those things need addressed before executing the tests in the pipeline will provide any value.

Look to Continually Add Value

You need to be willing to continually look at what is adding value to your CI/CD process and/or pipeline. In some cases you could add value by removing a certain check that has proven to either be pointless or needs work before it can be re-introduced. Take a look at incoming defects and see where things were missed and determine if a step in the process needs changed or refined. If a particular step takes a long time to complete and causes a bottle-neck then see what can be done to speed it up. The value in CI/CD is in the reliability of repeatability. When you are maximizing productivity and quality at the same time you will find you are in the CI/CD "sweet spot"