Build Priority Switching via Resource Usage Patterns
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In continuous integration (CI) and continuous deployment (CD) server environments, users cannot change the scheduled priority of their builds once they have been executed, as such changes can adversely affect other users' builds, leading to potential disruptions in computing resources.
Innovation Solution
A user interface is provided that allows users to switch build priorities based on resource usage patterns, limiting prioritization to user-prioritizable builds determined by statistical indicators of resource consumption, ensuring fairness and minimizing disruptions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If users are allowed to change build priorities after execution has begun, then user flexibility and control are improved, but system stability and fairness to other users deteriorate
Solution Approach 1:
The system applies different priority change rules to different builds based on their resource usage characteristics. Builds are categorized into prioritizable and non-prioritizable groups, with only those showing stable resource usage patterns allowing priority changes. This localized application of flexibility resolves the contradiction by permitting adaptability only where it will not harm system stability.
Solution Approach 2:
The system performs preliminary analysis of resource usage patterns before allowing priority changes. By evaluating historical resource consumption data and predicting future usage, the system pre-determines which builds are safe to reprioritize. This preliminary action prevents instability by identifying only those builds whose priority changes will not adversely affect other users.
2Reliability
If priority changes are restricted to maintain fairness, then system stability is improved, but user control and responsiveness deteriorate
Solution Approach 1:
The system continuously monitors resource usage patterns and provides feedback to determine priority change eligibility. By analyzing resource consumption data and comparing it against established patterns, the system dynamically determines which builds allow user intervention. This feedback mechanism maintains stability by preventing harmful priority changes while preserving user control where appropriate.
Solution Approach 2:
The system dynamically adjusts the level of user control based on real-time resource usage patterns. Builds exhibiting stable, predictable resource consumption allow user priority changes, while those showing volatile patterns restrict such changes. This dynamic approach resolves the contradiction by adapting user control permissions to current system conditions rather than applying static restrictions.
3Reliability
If resource usage patterns are analyzed to determine prioritizable builds, then fairness to other users is improved, but system complexity and processing overhead increase
Solution Approach 1:
The system applies partial analysis by focusing only on key resource usage metrics rather than comprehensively analyzing all system parameters. By monitoring specific resource consumption patterns relevant to fairness determination, the system achieves adequate fairness assessment without the complexity of full system state analysis. This selective approach maintains fairness while limiting complexity growth.
Data Source
AI summary
A processing device in a system can allocate builds to execute jobs across servers in a distributed server environment such as a continuous integration (CI) or continuous deployment (CD) server environment, determine workload patterns, and store a workload pattern vector including a resource usage pattern for the builds and the servers. The processing device can provide an interface that allows a user to switch priorities of user-owned builds in server environments, even after execution of the jobs has begun. The user's ability to prioritize or reprioritize builds is limited to user-prioritizable builds as determined based on the resource usage patterns of the builds running the jobs. The user can thus prioritize some user-owned builds without adversely affecting builds of other users.