While building a CI/CD pipeline, consider your need to create a project and add team members to it. The project dashboard provides visibility to the code flow through the deployment pipeline, monitoring the build, triggering alerts, and tracking application activities. The following diagram illustrates a well-defined DevOps pipeline:

Consider the following points while designing the pipeline:

• Number of stages: Stages could be development, integration, system, user acceptance, and production. Some organizations also include dev, alpha, beta, and release stages.
• Type of tests in each stage: Each stage can have multiple types of tests such as unit tests, integration tests, system tests, UATs, smoke tests, load tests, smoke tests, and A/B tests at the production stage.
• The sequence of a test: Test cases can be run in parallel or need to be in sequence.
• Monitoring and reporting: Monitor system defects and failures and send notifications as failures occur.
• Infrastructure provisioning: Methods to provision infrastructure for each stage.
• Rollback: Define the rollback strategy to fall back to the previous version if required.

Having a system that requires manual intervention where it's avoidable slows down your process. So, automating your process using CD will accelerate your process.

Another common anti-pattern is keeping configuration values for a build inside of the code itself, or even having developers use different tools in their build processes, which can lead to inconsistent builds between developers. It takes lots of time and effort trying to troubleshoot why particular builds work in one environment and not in others. To overcome this, it is better to store build configurations outside of code. Externalizing these configurations to tools which keeps them consistent between builds, enables better automation, and allows your process to scale much more quickly. Not using a CD process can lead to last-minute, middle-of-the-night rushes to get a build to work. Design your CD process to fail fast, to reduce the likelihood of any last-minute surprises.

Nowadays, most applications are built as a web app and utilize a cloud platform. To apply architecture best practice at each step of application development, the twelve-factor methodology can be used, as recommended by The Twelve-Factor App (https://12factor.net/), the twelve-factor methodology adopted by enterprises for end-to-end development and delivery of web applications. This applies to all coding platforms regardless of programming languages. You have learned details about each factor throughout different chapters of the book.