Timing is everything. Whether you're a solo developer meticulously crafting your passion project, a DevOps wizard orchestrating the symphony of continuous integration and deployment, or an enterprise architect overseeing a complex mono-repo structure, your success hinges on the smooth and timely execution of builds.
That's why Bitrise is thrilled to announce our latest innovation: a flexible build scheduler that adapts to the unique rhythms of your development lifecycle.
What's New? Bitrise's flexible Build Scheduling unveiled
Not so long ago, our build scheduler was like a metronome locked to a single tempo – useful, but hardly versatile. Developers were confined to triggering builds on a daily or weekly basis, choosing specific weekdays for automation. This one-size-fits-all approach overlooked the nuanced cadences of mobile development, where the need for builds could span a spectrum from multiple times a day to a few times a year. We realized that what you needed wasn't a metronome, but a conductor's baton – a tool that could harmonize with your project's tempo, no matter how irregular or intricate.
Enter Bitrise's revamped build scheduler. You can now set up build schedules of your choice. Some examples below:
- Every “X” minutes
- Every “X” hour
- Every “X” day
- Every Mon, Tue at 15:00
- Every weekday at 15:00
- Every day at 15:00
- Every 2 weeks on Thu at 15:00
- Every 4 weeks on Fri at 15.00
- Every month on day 28 at 15.00
- Every “2” months on day 22 at 15:00
- Every “2” months on the third Tuesday at 15:00
- Every year on the first Monday of March at 15:00
- Every year on Mar 22 at 15:00
Introducing the Cron-Based Scheduler
For those who crave even more control and precision, Bitrise now offers a Cron-Based Scheduler. This feature allows you to use cron syntax to define highly specific and flexible build schedules. With cron, you can schedule builds to run at exact times, down to the minute, and set complex patterns that match your development needs.
Examples of Cron Expressions:
- 0 0 * * * - Runs at midnight every day.
- 30 14 * * 1-5 - Runs at 2:30 PM on weekdays.
- */15 * * * * - Runs every 15 minutes.
- 0 9,17 * * 1-5 - Runs at 9:00 AM and 5:00 PM on weekday
Benefits of using cron syntax
Granular Control
Cron syntax allows for precise scheduling down to the minute. Users can specify exact times, days, and even ranges (e.g., every weekday at 3 PM or every 15 minutes between 1 PM and 3 PM), which is difficult to achieve with a UI-based approach.
Flexible patterns
Cron supports complex scheduling patterns, including specific time ranges, intervals, and combinations. This flexibility enables configurations like running jobs every 5 minutes during business hours on weekdays, which would be cumbersome to set up in a UI-based scheduler.
Efficiency and resource optimization
With cron, you can optimize resource usage by scheduling builds during off-peak times or distributing them to balance server loads efficiently. This precise control helps avoid unnecessary builds and maximizes resource efficiency.
Scalability
As your projects grow, the complexity of scheduling can increase. Cron-based schedulers handle these complexities better, eliminating the need for extensive manual configuration typical of UI-based schedulers.
Standardization
Cron syntax is a widely understood standard, making it easy for teams to adopt and ensuring consistency across various environments and projects. This standardized method of scheduling is well-documented and familiar to many developers.
Let's dive into some real-life scenarios where this feature doesn't just add convenience but transforms workflows:
Scheduled builds vs Triggered builds
There are many reasons why you would prefer to schedule CI-CD work, so it doesn't just execute when you push code to a repository or open up a PR. Understanding the distinction between scheduled builds and triggered builds helps you optimize the automation of your development pipeline.
Scheduled Builds: Scheduled builds are exactly what they sound like — builds that are pre-set to run at specific times or intervals, regardless of other activities in the repository. They are the drumbeat of your development process, set to a timer that you define. Here's what sets them apart:
- Time-based: You can set scheduled builds to run at regular intervals (e.g., minutely, hourly, daily, bi-weekly, etc). This is akin to setting an alarm clock for your build process.
- Consistency: Scheduled builds provide a consistent rhythm for maintenance tasks such as nightly builds, weekly regression tests, or monthly security checks, ensuring regular attention to various aspects of the project without the need for manual initiation.
- Predictability: Since the timing of scheduled builds is known in advance, teams can plan around them, preparing for testing phases, reviews, or deployments that follow these builds.
- Non-event driven: Scheduled builds are not dependent on code commits, pull requests, or other repository events. They run purely based on the clock.
Triggered Builds: Triggered builds, on the other hand, are initiated by specific events in the version control system. They are the reflex response of your CI/CD process to changes in your codebase. Characteristics of triggered builds include:
- Event-Based: These builds are typically triggered by actions such as code commits, pull requests, merges, or even comments on a pull request. They are reactive, automatically starting when a predefined event occurs.
- Dynamic: Triggered builds are dynamic and can occur at any time, depending on when the triggering event takes place. This is ideal for teams that need immediate feedback on changes made to the codebase.
- Adaptive: Because they are tied to repository events, triggered builds adapt to the development workflow's pace, ensuring that each change is tested as it comes in.
- Customizable: Many CI/CD platforms allow you to customize which events trigger a build and even define different actions or workflows based on the type of event or branch involved.
In summary, the primary difference lies in their initiation: scheduled builds run based on the clock, providing a steady, predictable rhythm of checks and updates, while triggered builds are event-driven, providing immediate, automated feedback to code changes.
Both types of builds are integral to a mature CI/CD setup, offering different advantages that help maintain software quality and streamline the development and deployment process
When to use scheduled builds
The traditional style of chain-reaction execution of builds based on events is not always enough. There are many reasons why you'd like to schedule CI-CD work, so it doesn't just execute when you push code to a repository. Here are a few
- Comprehensive testing: Scheduled builds can be used to run the full suite of tests, including those that are costly and time-consuming, such as functional, UI, and integration tests, which might not be feasible to run on every commit. A nightly build, for example, can verify that the software is functioning as expected, with results ready at the start of the next working day.
- Regular performance scans: You must run regular scans to monitor and action performance metrics. By scheduling these, you can keep the necessary performance and security scans running regularly and on time.
- Security checks outside the normal commit-push cycle: As cyber threats grow more frequent and severe, continuous security in software development is essential. Traditional CI pipelines, which trigger new commits, may not suffice due to the rapid emergence of vulnerabilities. Regular, scheduled security scans are necessary, especially for compliance-heavy industries or sensitive applications. These scans, set at specific intervals, ensure persistent protection, independent of standard CI/CD triggers, and keep critical software safeguard
- Sending reports: Scheduled builds enhance transparency and communication by consistently updating teams and stakeholders on application statuses and other critical metrics. By automating your builds, not only can you deploy them for a review, but you can also systematically distribute emails, refresh dashboards, update documentation, and execute various reporting tasks. This automation ensures that everyone involved stays informed and confident in the ongoing work.
- Accessibility of latest builds: Regularly scheduled builds ensure that teams outside development, including product managers, QA engineers, and other stakeholders, always have access to the latest version of the software under development.
- Flexible cadence: The rhythm of these builds can be tailored to the project's needs — not just nightly, but every few hours, or even multiple times per hour, depending on the desired frequency.
Coming soon - Cron-based scheduling
Those who crave even more control and precision in their scheduling, stay tuned. We're gearing up to introduce cron-based scheduling, offering you the granularity to tailor your automation to the exact minute, matching your team's rhythm like never before. Get ready to fine-tune your CI/CD schedules with the power and flexibility of cron expressions, coming soon.
.jpg)
.jpg)
