7 Matching Annotations
  1. Dec 2021
    1. it is best to limit the number and scope of branches in your repository. Most implementations suggest that developers commit directly to the main branch or merge changes from their local branches in at least once a day.

      Actually this is the "agile" motto - release early, so no long feature-branches.

    2. discovering failures as early as possible is important to minimize the resources devoted to problematic builds. To achieve this, prioritize and run your fastest tests first. Save complex, long-running tests until after you’ve validated the build with smaller, quick-running tests.

      Build articulated jobs to identify early low-hanging spoiled fruits.

    3. When making these significant decisions, make sure you understand and document the trade-offs you are making.

      Leave a coherent trail about the decisions behind the CI machinery.

    1. So while running “all tests” in all builds would be ideal, reality dictates that we prioritize testing and run certain types of tests in certain stages of the dev/test cycle. There are a few ways to achieve prioritized testing:Having one automated build process that runs only the basic set of tests, and trigger additional tests manually.Having several build configurations: one for a basic set of tests, one including some more tests, up to the full production build which includes all tests. These sets of tests create numerous builds that are using almost the same artifacts, creating duplication and room for error. Not to mention maintenance-hell. Also, this approach limits flexibility to some extent. For example, what if a developer wants to execute a specific automated UI test to see if a change broke the interface? That will have to wait for later in the dev/test cycle.

      Describe the need for flexibility to select one out of multiple build/test configurations.

      Not really providing practical advises.

  2. Sep 2021