Patterns for Designing CI/CD Workflows

Patterns for Designing CI/CD Workflows Leandro Sousa1 and Filipe Correia1

arXiv:2611.17276v1 [cs.SE] 12 Nov 2026

INESC TEC, Faculty of Engineering, University of Porto, Portugal {up202300371,filipe.correia}@fe.up.pt

Fail Fast Context. A pipeline composed of multiple interdependent phases/steps. Problem. In the event of a failure at any stage of a pipeline, the outcome of the workflow is predetermined. However, the pipeline continues to execute subsequent steps, the results of which are contingent on the failed step. In the event of a failure, how should the pipeline behave? Forces. – Early Feedback vs Failure Visibility — Aborting the pipeline after a failure reduces time and resources, but may hide other failures that maybe revealed later in the execution. – Diagnostic Completeness vs Results Validity — The goal is to derive maximum diagnostic value from each workflow execution, yet the steps that depend on a failed step may run on invalid or non-existent inputs, so the result information might be misleading, contributing to noise rather than information. – Diagnostic Completeness vs Results Validity — A pipeline execution should run all steps that have the potential to reveal a problem; however, it should be noted that execution time and executor capacity are both finite and shared across the team, or organization. Thus, the execution of a workflow that has already been identified as failed will delay the progress of all other tasks. Solution. Design your pipeline so that, when a part of it fails, other dependent parts are not executed and automatically fail instead [2, 5]. Consequences. ⊕ Developers can catch the failures earlier has they receive feedback sooner. ⊕ There is no wasted time and resource in the dependent steps. ⊖ Latent defects might remain undetected until further pipeline executions. Related patterns. The Single-Responsibility Steps is a key Pattern that enables this Pattern effectiveness as stopping for failing fast a workflow can be more precise that the granularity of the steps themselves. The use of specific, smaller steps help to reveal the independence between checks which enables this pattern. Combining the two comes at a cost: finer steps mean a larger dependency graph must be declared and maintained. Applying first Single-Responsibility Steps enable a better implementation of Fail Fast.

2

L. Sousa and F. Correia

Single-Responsibility Steps Context. A pipeline workflow uses custom workflow definition maintained and authored by a specific team. Problem. A step may be the most granular part of a workflow. Thus, encompassing unique name, failure point, retry mechanism, caching and reporting mechanisms. A step that performs multiple actions report a single result while a workflow with split steps solve this it carries its own declaration and setup cost. How can we determine the work a step should do? [6] Forces. – Diagnostic simplicity vs Orchestration complexity — It is imperative that failures are immediately apparent and straightforward to find, thus encouraging the division of the workflow into single-responsibility steps; However the addition of further jobs and steps with their own declaration can make this decomposition that make failures easily found make the workflow progressively hard to read and change. – Step isolation vs State continuity — It is imperative that the steps are executed in an independent manner, thus ensuring that a potentially unreliable step does not compromise the integrity of the whole workflow. However, independent steps remove the implicit shared state of a single script. Thus, every data that needs to be shared across steps must be passed explicitly. Solution. Try to make each step in a workflow as simple and self evident as possible by limiting the number of commands it executes to the essentials, as well as naming the step if necessary [8, 5, 6]. Consequences. ⊕ Clear and simple steps makes easier to understand the CI/CD workflow. ⊕ By breaking pipeline tasks down into specific steps, a pipeline failure is transformed into easy locatable steps. ⊖ Breaking a pipeline into small specific steps can result into spread configurations which can decrease the overall pipeline execution time. Related patterns. Fail Fast make this Pattern worthwhile. Creating single-responsibility steps improves how can maintainers control how the pipeline behave, combining this with Fail Fast skips the downstream steps after a failure.

Interrupt Outdated Pipeline Runs Context. Pipelines where only their most up to date results matter. Problem. Teams and developers pushes multiple times in a short period of time causing multiple pipeline executions. The first run is still execution when the last arrives so there are concurrently executions. The code introduced before the last execution has already been replaced, thus it is a wast of time and computational resources to continue

Patterns for Designing CI/CD Workflows

3

a pipeline run when its input is outdated. Outdated pipeline results are irrelevant. A pipeline’s result is outdated when the input used to generate that result is older than the most recent input [2]. Forces. – Increase available capacity vs Discard completed work — If a run is superseded we want to reclaim the runner capacity as fast as possible. Nevertheless, interruption a pipeline in a mid-way step throws away already finished work, such as, cache and built artifacts that the most recent run should produce again. – Latest result vs History — The last result is the most important since is the one that will end up in the next stage of the SDLC. However, a branch whose intermediate runs never end up cannot be reviewable, bisected and auditable. – Abrupt Interruption vs Graceful Interruption — A step that take actions against target, for example mid-way through the deployment, leave the pipeline in state where interrupting the run is more damaging than letting it finish. Solution. There is a need to have concurrency groups derived from the branches or pull request developers are working on where a pipeline run should be assign to. Design then your pipeline so that, when a new pipeline run needs to start, previous runs based on now-outdated input are stopped. Irreversible side effects jobs and steps should be excluded from cancellation [8, 2]. Consequences. ⊕ A developer do not need to wait for the other runs to be executed to get its feedback. ⊕ A developer receives a single result rather than multiple results from the different commits. ⊖ Only the last run is judged, leaving the intermediate pipeline runs without verdict, which can hide developer feedback. Related patterns. Single-Responsibility Steps determine where a pipeline run can be gracefully interrupted since a step compasses the evaluation to determine the risk for a step to be canceled.

Workflow Component Template Context. Multiple similar jobs with only partially varying implementations. Problem. A maintainer create a job/step to a set of actions for a service, then copies it for another service, and so on. Later something need to change across all service in that job/step, meaning that every job/step created for each service need to be updated. Fully defining each implementation of similar jobs will result in unnecessary repeated code. This is because: Each job shares identical logic. This logic has to be defined for each full implementation of the job. Forces.

4

L. Sousa and F. Correia

– One place to edit vs Readability — Maintaining a single definition is better when logic is shared shared. Nevertheless, reading the job can no longer show what it have run decreasing readability of that pipeline definition and execution. – Variants vs Readability — Team want a template to cover every job that is nearly the same, but each job variant add a condition or parameter turning the template into a control flow harder to read. – Big Bang vs Blast Radius — We want to propagate the change at once but a mistake reach the consumers as fast as the propagation. Solution. Define a template containing all the logic each implementation will share. Implement the template in a way that allows its behavior to be adjusted by specific implementations. Define each specific implementation so that it exclusively adjusts the behavior of relevant sections of its template [4, 3]. Consequences. ⊕ ⊕ ⊕ ⊖

Shared logic is fixed at once rather than for each implementation. Implementation that should behave alike can share code. Implement a similar service is faster. Fixing a step is easy but it can add defects to other implementations.

Related patterns. Single-Reponsibility Steps are the pieces that can be used within templates.

Event-based Triggering Context. A software project has different CI/CD workflows corresponding to different action that need to be executed depending on certain events — Pull Requests, commits, issue activities, tag, and many others — These events happen at unpredictable times nor their frequency is known in advance. Problem. There’s no suitable fixed schedule for unplanned events. Scheduled workflow runs either wastes resources or leaves events unprocessed. Relying on developers to manually trigger workflows means execution depends on memory and availability. How can the appropriate workflow be started promptly and reliably every time an event occurs? [14, 12, 3] Forces. – Feedback Speed vs Resource Consumption — The sooner the developer has feedback the better for developer act promptly. However, every run uses computational resources and pipeline can be triggered faster than they complete. – Automation vs Control — Events that trigger specific workflows guarantee that no manual execution is required, but it also remove the ability to choose when a particular change don’t need to trigger a workflow. – Trigger granularity vs Configuration Simplicity — The granularity of the events that trigger a workflow avoid unnecessary executions, however each aditional eventbased condition added to the workflow configuration file make it hard to understand.

Patterns for Designing CI/CD Workflows

5

Solution. Adjust your CI/CD so that certain workflows are subscribed to specific events. Whenever a matching event to a workflow occurs, that workflow is triggered [3, 5]. Consequences. ⊕ Feedback arrive fast for the developer to act promptly. ⊕ Trigger is no longer human dependent for the day-to-day activities. ⊖ Workflow runs become unpredictable, therefore infrastructure need to provide capacity for peaks that might occur. ⊖ The number of executions that an event trigger cannot be controlled, therefore it can generate computational waste, unless interruption mechanisms are implemented. Related patterns. Interrupt Outdated Pipeline Runs is complementary to this pattern in order to solve one of its disadvantages, the number of executions that an event trigger. Therefore, any workflow that is trigger based on the same event can be suppressed. Also, Scheduled-Triggering has can cover specific workflow runs that this pattern cannot serve and Manual Triggering where it can keep the human able to trigger when automatic is not desirable.

Manual Triggering Context. A software system implementing workflows that need only be triggered sporadically and ad hoc. Problem. Some workflows need only be run at irregular intervals. Sometimes the triggering conditions of these workflows cannot be defined programmatically. How should such workflows be triggered? [14, 13, 5, 4, 1] Forces. – Flexibility vs Reproducibility — Human control of the workflow parameters and execution time make the workflow serve different proposes and fit a lot of situations, however make every run potentially different. Solution. Adjust your CI/CD infrastructure so that certain workflows are triggered manually. Consequences. ⊕ Gives a deliberate control over a workflow. ⊕ Resource consumption is not unpredictable. ⊖ Workflow execution depend on a human. Related patterns. This pattern cover the cases Event-Based Triggering and Scheduled Triggering cannot cover. It can act as the vehicle to manual rollback which implements the Rollback Strategy.

6

L. Sousa and F. Correia

Scheduled Triggering Context. A software system implementing workflows that need to be triggered at regular intervals. Problem. Some workflows must be executed at regular intervals (for example, workflows related to pipeline monitoring or to trigger test automation). How can we best ensure such workflows are triggered regularly? Forces. – Detection Latency vs Resource Consumption — Shorter interval runs may reveal problems fast, however it increase resource consumption. Solution. Adjust your CI/CD infrastructure so that certain workflows are triggered automatically at predefined intervals [3, 1, 2]. Consequences. ⊕ . ⊖ An error introduced after a scheduled run stays undercover. ⊖ . Related patterns. This pattern is the alternative to Event-Based Triggering, has can be used to execute work that is too slow or costly to run on every change. Manual Triggering is the other pattern to be used for human decision workflow runs.

Filter External Input Context. The workflow uses input generated by an entity that it does not have complete control over. Problem. Workflows can be compromised by third-parties. This is because: If any part of a workflow is compromised, the entire workflow may be compromised as well. A software system cannot guarantee the integrity of what falls beyond its control. External input can potentially be compromised (intentionally or unintentionally) by third parties [9, 7]. Forces. – Security vs Sanitization — By filtering the external input we can improve the security of a workflow, however, excessive filtering may hide useful information or change the workflow behaviour. – Solution. Validate, filter and sanitize external input, before process the workflow in order to ensure no potentially harmful data is used by the workflow. Consequences. ⊕ Reduce the risk of external input compromises the workflow.

Patterns for Designing CI/CD Workflows

7

⊕ Improve the overall reliability of the workflow. ⊖ Excess filtering may reject useful inputs. ⊖ The overall complexity of the workflow increases has it introduces additional processing. Related patterns. Deterministic Dependencies complements this pattern as it implements a way to filter data that enters a workflow by pinning the version that can be downloaded. Permission Management can act as a limiter to the damage an external injection can do.

Notification Mechanisms Context. A software system development or maintained by a team or a group of teams. Problem. Issues detected in a pipeline may go unnoticed and unfixed for prolonged periods of time. This is because: During the execution of a pipeline, there are often issues which require manual input to be resolved (for example: fixing code that fails builds or tests). Fixing these issues quickly is essential to maximizing the efficiency of a pipeline. These issues often reveal themselves at unpredictable times. Developers are not constantly monitoring detected issues or the pipeline behaviour [12, 5, 4, 3, 1]. Forces. – Actionability vs Disruption — Timely notifications improve the responsiveness required for a developer to act promptly, nevertheless, numerous alerts that do not reveal actionable steps can be distracting and contribute to fatigue. Solution. Implement notification mechanisms to alert relevant parties about a workflow behavior that require human to look into its result [4, 3, 1]. Consequences. ⊕ Reduces the issue resolution time. ⊕ Has relevant parties receive feedback about the pipeline behavior, it increases the pipeline efficiency. ⊕ It can enhance visibility of pipeline failures and the actions that are required. ⊖ The phenomenon of alert fatigue can be observed, resulting from excessive or poorly targeted notifications. ⊖ This mechanisms depends on the integration with the target app that receive notification, this need further configuration and may add costs. Related patterns. The notifications that this pattern delivers can be produced by Selfmonitoring Pipelines. This pattern also enables Fail Fast as a failing fast is only useful if someone gets notified. Furthermore, it’s important for the Rollback Strategy has rollbacks need to be notified.

8

L. Sousa and F. Correia

Rollback Strategy Context. A software system that is delivered to stakeholders through large, infrequent releases. Problem. A previous version of a software system may be superior to its most recent version. This is because: A software system most often requires numerous changes in order to adapt to the ever-shifting needs of its users. These changes should be applied as quickly as possible in order for users to have access to up-to-date functionalities. There always exists a possibility that a change will introduce unexpected issues into a software system that make its current version worse than the previous one [5, 4]. Forces. – Time to recover vs Complexity — Implementing fast rollback mechanisms have the effect of reducing downtime and disruption. However, it should be noted that such mechanisms may require additional infrastructure, processes and version control. – Frequent releases vs stability — Frequent releases deliver faster value customers, but each new delivery may hurt software stability increasing the the risk of introducing bugs. Solution. Structure the software system in a way where it can easily be restored to an earlier version and subsequently distributed to its users [5, 4]. Consequences. ⊕ ⊕ ⊕ ⊖

Reduces the risk of introducing bugs to customers. Reduces deployment failures. Increase release confidence. Requires versioning and rollback processes.

Related patterns. Notification mechanism has its important to alert that software has been rollback. Recovering from a fault can be done in different ways, with one such option being the use of a Fast-lane for Hot-fixes.

Task Parallelization Context. Pipeline with independent steps. Problem. Executing a pipeline as a single continuous operation tends to lead to an under- performance of the hardware used to run the pipeline. This is because most modern hardware has been designed to perform best when executing multiple operations at once. Forces. – Speed vs Complexity — Executing tasks in parallel increase pipeline speed, however it increase the complexity to design and maintain pipeline steps coordination.

Patterns for Designing CI/CD Workflows

9

– Resource Utilization vs Resource Competition — Executing tasks in parallel increase the resource utilization, but it increase the change of race to conditions where pipeline compete for resources. Solution. Design your pipeline to harness the potential of the hardware it relies on by parallelizing its execution [11, 1]. 1 Consequences. ⊕ ⊕ ⊖ ⊖

Reduce the execution time. Enhance the usage of the available resources. Increased complexity for the pipeline steps dependencies. Parallelization design must be well design to have race to condition.

Related patterns. The pattern relies on the division of workflow into smaller (SingleResponsibility Steps), independent units that can be executed simultaneously.

Prioritize Failed Jobs Context. Pipeline with independent jobs. Problem. Often, resources are wasted by re-running a pipeline only for it to fail on the same job as its previous execution. This is because: Running a pipeline consumes resources. Normally, a job failing leads to the entire pipeline execution failing. When a job causes a pipeline to fail, the next pipeline execution with similar input is more likely to fail on that job than on other jobs. The predefined order of a job in a pipeline is not directly related to how likely it is to fail for a given input. How can a pipeline minimize the resource spent on failing subsequent pipeline? Forces. – Optimal Failure Ordering vs Dependencies Constraints — The jobs/steps that are more likely to fail should run sooner, however the workflow steps dependencies limit how jobs/steps can be ordered. Solution. Implement a mechanism that orders job execution so that jobs that failed during previous executions of a pipeline are run earlier in the pipeline whenever possible [2]. 2

Consequences. ⊕ ⊕ ⊖ ⊖

Reduce resource consumption. Shorten feedback loops. Require pipeline history. Previous failures may not predict new ones, limiting this pattern efficiency.

Related patterns. The idea behind Fail Fast is to stop early on when things go wrong, and that if something will probably fail anyway, then you should make that clear right at the start. 1 Many CI/CD providers partially abstract away the implementation of this pattern by automati-

cally using parallelization whenever possible 2 Prioritize Failed Jobs is dependent on the existence of an implementation of Fail Fast, where

the pipeline stops when a job fails.

10

L. Sousa and F. Correia

Fast-lane for Hot-fixes Context. A software system that is delivered to stakeholders through small and frequent releases. Problem. Forcing fixes for serious issues to pass through the same deployment pipeline as regular changes can lead to greater damages due to a longer time until deployment. This is because: No matter how well designed and extensive a deployment pipeline is, it is always possible for serious issues to slip through undetected. A serious issue in a software system needs to be resolved as soon as possible in order to minimize the extent of the damage caused by it. CI/CD pipelines associated with regular changes to the software system are normally quite extensive and consequently time consuming [4, 3]. Forces. – Speed vs Security — Implement a fast lane enable developers to solve issues promptly; Nevertheless, it can introduce security breaches as the full CI/CD pipeline is skipped. – Usage vs Pipeline Design — Fast lane are optimal and ideal for developer to act rapidly; However, this mechanism is tightly coupled to a pipeline design and process which need configuration and maintenance. Solution. Implement a separate deployment pipeline to be used by hot-fixes. Use this pipeline very sparingly and exclusively for urgent adjustments. Consequences. ⊕ Solve production issues fast. ⊕ Flexibility of the workflow. ⊖ Full CI/CD pipeline is skipped potentially introducing security problems as steps are skipped. ⊖ Maintenance is higher. Related patterns. Rollback Strategy is an alternative to this pattern and it reverts instead of fixing froward.

Build Different System Components Separately Context. A software system which has been (or which can be) divided into multiple loosely coupled modules. Problem. By always rebuilding the entire software system independent of the changes made to it, computational resources will be wasted. This is because: Building a software system consumes computational resources relative to its size. Some changes only affect certain parts of a software system. A part of a software system is always smaller than the whole software system. Forces.

Patterns for Designing CI/CD Workflows

11

– Resource Optimization vs Configuration — Despite the resource optimization that comes from this pattern implementation, has it rebuild only the affected component it increases the configuration effort has it need setup and new services need new configuration. Solution. Organize your pipeline so that only the parts of your software system affected by a change are rebuilt. Rely on previous build results for unchanged parts [5, 1]. Consequences. ⊕ Resource optimization. ⊖ Configuration become harder. Related patterns. Task parallelization enable even faster build if services can be built independently.

Self-monitoring Pipelines Context. CI/CD pipelines whose health is critical for the correct functioning of a software system. Problem. It is often difficult and inefficient to monitor CI/CD pipelines externally. This is because: To accurately identify characteristics that only reveal themselves during pipeline execution, a lot of information about pipeline runs is often required. Retrieving certain information from a pipeline’s runs from outside that pipeline is difficult, sometimes even impossible. Forces. – Observability vs Simplicity — The data of interest is only observable from within the pipeline; however, the placement of monitoring logic there results in the CI/CD being coupled with its own instrumentation. Solution. Leverage CI/CD values by implementing pipeline metric collection within your pipeline, and implement methods (manual or automatic) to analyze these collected metrics for issues [5, 4, 3]. Consequences. ⊕ Uniform methods on every pipeline run making trend analysis and regression detection easier. ⊕ Per-step observable data. ⊕ No external infrastructure, metrics are produced and collected directly in the pipeline. ⊖ Every pipeline execution time increase. ⊖ Maintenance increase. ⊖ Shared abstraction must be implemented, so no duplicated code is generated across different pipelines. Related patterns. Single-Responsibility Steps and Workflow Component Template ensure that the observability mechanisms are implemented without being duplicated across pipelines. Notification Mechanisms consumes the output generated of self-monitored pipelines.

12

L. Sousa and F. Correia

Permission Management Context. A software system whose contributors have varying levels of clearance. Problem. Entities can potentially use the CI/CD pipeline to access and tamper with assets they are not cleared to access. This is because: Due to the overarching nature of CI/CD pipelines, which reaches across most facets of a software system, a pipeline will normally have access to, and sometimes be able to modify, a software system’s sensitive information. CI/CD pipelines are generally used by every contributor of a software system. Some contributors of a software system may not have the proper clearance to access certain assets of said system [8, 7]. Forces. – Autonomy vs Control — Unrestricted pipeline management enable developers to act promptly and adapt their CI/CD to the circumstances that their product might need to adapt to. However the lack of control can lead to information exposure or malicious tampering. – Granularity vs Maintenance — Fine-grain permissions enable access only to the resources developers need, yet comes with the design and maintenance cost aligned with the organization. Solution. Implement and enforce a CI/CD pipeline permission management system adjusted to the structure of the organization that owns the pipelines [4, 1, 8, 7]. Consequences. ⊕ Developers can only reach the resources that they have permission to. ⊕ Permissions can mirror organization structure, enabling audit and traceability. ⊕ The blast radius of a potential harmful and compromising account is limited to the pipeline permissions. ⊖ Permission matrix model must be maintained. ⊖ Overly restricted pipelines can hamper software delivery. ⊖ The permission system become a single point of failure. Related patterns. This pattern complements the four eyes principle has it define how many people must agree and this pattern on who act.

The Four Eyes Principle Context. A software system with multiple contributors. Problem. Some important quality aspects cannot be automatically verified by a pipeline. This is because: Many aspects of software quality cannot be automatically evaluated, either because there exists no known method of automatic evaluation for them or because said method is prohibitively expensive. These aspects of software quality are oftentimes still relevant and should therefore be kept above certain thresholds. Forces.

Patterns for Designing CI/CD Workflows

13

– Coverage vs Human Judgment — Automation is repeatable and cheap, compared to human review, but only a human can assess certain design, and architectural intents. – Autonomous vs Manual Gate — CI/CD is design to be autonomous and run unattended, yet a manual gate deliberately includes a step that requires a human intervention and suspends the pipeline execution until an action is taken. Solution. Require another human collaborator to manually inspect/review the quality aspects of submitted changes which the pipeline cannot before admitting said changes into the repository. The approval method come from the CI/CD mechanisms so the verdict is a pipeline signal like any other automation in said pipeline [4]. Consequences. ⊕ Human intervention is based on automation that has already been implemented for the pipeline. Consequently the human decision is augmented by this automation. ⊕ Pipeline become source of auditing processes with the information who admitted which change. ⊕ It is not possible for a single contributor to make effective changes alone. ⊖ The manual gate hamper flow, as it introduces a wait state only a human can approve. ⊖ Time-to-market pressure can lead the approval gate into rubber-stamping making the gate redundant. ⊖ It is imperative that the gate is protected in order to ensure that only developers who have been granted the appropriate authorization are able to remove it or bypass it. Related patterns. Permission Management defines who is allowed to act, complementing this pattern. It should be noted that this pattern approach is in tension with the Fast-lane for Hot-fixes, which may require the relax of the review period to facilitate the deployment of urgent fixes.

Deterministic Dependencies Context. A software system that uses external dependencies. Problem. The behavior of software systems using external dependencies can be altered by changes outside of the software system’s control. This is because: The evolution of external dependencies is, by definition, completely or at least mostly outside of the control of those responsible for the pipelines that use them. Maintainers of external dependencies can modify interfaces or functionality, introduce errors, or otherwise alter an external dependency. If a dependency changes, so do the software systems that depend on it [13, 8–10, 7]. Forces. – Reproducibility vs Staleness — Pinning dependencies to a specific version ensures that every pipeline run uses the same dependency version, however this can result in the system becoming stale if no policy is in place to manage the updating of dependencies.

14

L. Sousa and F. Correia

– Updates vs Control — By using tag or references that floats, pipeline dependencies can automatically improve or get fixes, yet developers loose the control over what actually their pipeline do. – Maintenance vs Debugging — Maintain dependencies references up to date can be expensive, but chasing failures caused by upstream changes can be more expensive. Solution. When referencing an external dependency, make sure the reference used points to a static instance, thereby ensuring that your pipeline is independent of the dependency’s evolution [8, 9, 7]. Consequences. ⊕ ⊕ ⊖ ⊖ ⊖

CI/CD pipelines become reproducible. System changes are not assigned to third parties. Updates to the pipeline dependencies are no longer automatic. Accumulating updates makes the upgrade riskier. You must keep a mirror of a version of the dependency, so if the reference disappear you still have the possibility to use that version.

Related patterns. The Filter External Input pattern can complement this pattern as it addresses two key areas: firstly, the presence of untrusted inputs, and with this pattern the presence of untrusted code.

Selective Testing Context. Pipeline with tests targeting only subsections of a software system. Problem. Running all tests independent of the changes made to the software system will likely waste resources. This is because: Running tests inside a pipeline consumes resources. Committed code should be tested. Code changes need not affect the whole software system, many sections of code may remain unchanged. If a section of code does not change, the results of tests verifying said section also will not change. Forces. – Coverage vs Resource Usage — The implementation of a comprehensive testing strategy is an essential component of ensuring system coverage. However, it should be noted that this approach entails an investment of time and resources, despite the possibility that the outcomes may remain unchanged. – Feedback Speed vs Confidence — A concise, focused run ensures the flow of developers, while a comprehensive run provides the most robust coverage of the system’s integrity. – Selection accuracy vs cost — The selection of the tests that will run needs an analysis, which is a process that must be undertaken, managed and trusted. Solution. Adjust your pipeline so that, when code changes are processed, only the tests whose result is affected by these changes are run [11]. Consequences.

Patterns for Designing CI/CD Workflows

15

⊕ ⊕ ⊕ ⊖

CI/CD consume less resources. Failures diagnosis are easier to detect. CI/CD can run often. Incorrect test selection can result in the skipping of essential testing, thereby facilitating regressions. ⊖ The test selection need extra pipeline configuration, which need to be maintained. ⊖ Different runs execute different tests, meaning a green pipeline no longer means that it has executed the same thing. Related patterns. Single-Responsibility Steps enable this pattern to use the granularity that determines which tests runs. Build Different System Components Separately highlights the change, therefore it facilitates the selection of which tests should be executed.

References 1. Bajpai, G., et al.: CI/CD Design Patterns: Design and implement CI/CD using proven design patterns. De Gruyter, first edn. (2024), https://www.scopus.com/inward/record.uri?eid=2s2.0-105022959284 2. Bouzenia, I., Pradel, M.: Resource usage and optimization opportunities in workflows of GitHub actions. In: Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE ’24). Association for Computing Machinery, Lisbon, Portugal (2024). https://doi.org/10.1145/3597503.3623303 3. Duvall, P.M.: Continuous integration: Patterns and antipatterns. DZone Refcard #84. http://bit.ly/l8rfVS (2010) 4. Duvall, P.M.: Continuous delivery: Patterns and antipatterns in the software life cycle. DZone Refcard #145. https://dzone.com/refcardz/continuous-delivery-patterns (2011) 5. Duvall, P.M., Matyas, S., Glover, A.: Continuous Integration: Improving Software Quality and Reducing Risk. Addison-Wesley (2007) 6. Gallaba, K., McIntosh, S.: Use and misuse of continuous integration features: An empirical study of projects that (mis)use Travis CI. IEEE Transactions on Software Engineering 46, 33–50 (2020). https://doi.org/10.1109/TSE.2018.2838131 7. Huang, J., Lin, B.: Revisiting security practices for GitHub actions workflows. In: 2025 IEEE/ACM 33rd International Conference on Program Comprehension (ICPC). pp. 73–77. IEEE (2025). https://doi.org/10.1109/ICPC66645.2025.00016 8. Khatami, A., Willekens, C., Zaidman, A.: Catching smells in the act: A GitHub actions workflow investigation. In: 2024 IEEE International Conference on Source Code Analysis and Manipulation (SCAM). pp. 47–58. IEEE (2024). https://doi.org/10.1109/SCAM63643.2024.00015 9. Li, X., et al.: Toward understanding the security of plugins in continuous integration services. In: Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security (CCS ’24). pp. 482–496. Association for Computing Machinery, Salt Lake City, UT, USA (2024). https://doi.org/10.1145/3658644.3670366 10. Pan, Z., et al.: Ambush from all sides: Understanding security threats in open-source software CI/CD pipelines. IEEE Transactions on Dependable and Secure Computing 21(1), 403–418 (2024). https://doi.org/10.1109/TDSC.2023.3253572 11. Urdih, F., Theodoropoulos, T., Zdun, U.: Architectural design decisions and best practices for fast and efficient CI/CD pipelines. In: European Conference on Software Architecture. pp. 297–305. Springer (2025). https://doi.org/10.1007/978-3-032-02138-0_19

16

L. Sousa and F. Correia

12. Vassallo, C., et al.: Automated reporting of anti-patterns and decay in continuous integration. In: 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). pp. 105–115. IEEE (2019). https://doi.org/10.1109/ICSE.2019.00028 13. Vassallo, C., et al.: Configuration smells in continuous delivery pipelines: a linter and a six-month study on GitLab. In: Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2020). pp. 327–337. Association for Computing Machinery, Virtual Event, USA (2020). https://doi.org/10.1145/3368089.3409709 14. Yaşa, A., et al.: Do developers fix continuous integration smells? In: Proceedings of the 19th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE 2023). pp. 12–21. Association for Computing Machinery, San Francisco, CA, USA (2023). https://doi.org/10.1145/3617555.3617870

Related documents

• Patterns for Designing CI/CD Workflows#1661293
• Understanding rituals#1255253
• Edifice complex#1190335
• The edifice complex#1191106
• Towards Equity Focused Approaches to EdTech: Methods and Ethics: Metadata and Documentation, 2022-2026#437899