4

I've been doing research on CI (continuous integration) and I can't find any info on the changes CI would introduce to ticket sizing.

CI states developers should merge to the mainline every day (or even multiple times a day), but if that is the case doesn't that mean when sizing tickets those tickets would have to be broken down into even smaller tickets that would only take a day or less to complete or am I just integrating fragments of code that pass unit test but are not the complete ticket?

example: say I have a ticket that my team would normally size a 3 which would equate to 5 working days, under CI rules would a developer be integrating the commits (that pass unit testing) he or she did for that day into the mainline (keeping in mind the ticket is still not complete) or is that ticket to large for CI and in turn the ticket would need to be broken down into smaller tickets where each one of those new smaller tickets would need to be done in a day or less?

0
6

under CI rules would a developer be integrating the commits (that pass unit testing) he or she did for that day into the mainline

The features you are developing should be developed in pieces, so that you can continuously verify they pass all your builds/tests. Hopefully your CI processes are setup to run on your branch as well as your master.

If you are working on a repository which is quickly moving (lots of merges to master), when working on a feature branch you should be often pulling in and merging with master.

Then, when you make your commits you are working very closely on what is currently your master branch. When this triggers CI you are getting the benefit of CI - validation and feedback regarding your current code.

However if you can't run CI on branches without having your code merged into master or cannot trigger CI to run on a branch, you should probably split your ticket up.

Pragmatically a lot of this is going to depend on your team workflow. If you only have a few merges a week the answer is less important than if your team merges 20 times a day. You want to avoid branch drift and particularly "CI branch drift" if you cannot run CI on branches.

is that ticket to large for CI and in turn the ticket would need to be broken down into smaller tickets where each one of those new smaller tickets would need to be done in a day or less?

Not strictly required, though it's a decent idea anyways.

The point of CI is to run automated processes when you commit/merge code. If you are not doing this, and waiting 5+ days prior to doing so, you aren't really doing CI. That's fine and if that process works for you great - it's just not really parallel to the core ideas of CI. Amazon Web Services has a really good definition on their site (emphasis mine):

Continuous integration is a DevOps software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run. Continuous integration most often refers to the build or integration stage of the software release process and entails both an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate frequently). The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.

In the past, developers on a team might work in isolation for an extended period of time and only attempt to merge their changes to the master branch once their work was completed. This batched process made merging accumulated code changes difficult and time-consuming. This is compounded when small bugs accumulate for a long time without correction. These factors combined made it harder to deliver updates to customers quickly.

With continuous integration, developers frequently commit to a shared repository using a version control system such as Git. Prior to each commit, developers may choose to run local unit tests on their code as an extra verification layer before integrating. A continuous integration service detects commits to the shared repository, and automatically builds and runs unit tests on the new code changes to immediately surface any functional or integration errors.

If you aren't doing this, you by and large will "not be doing CI" - but again, this is dependent on your team workflow. But recognize batching feature changes is nearly the exact problem situation that having CI types of processes were developed to solve (see the Amazon definition).

1
  • ah ok, so automation is the name of the game. the point is to do build test whenever something is added to the repository whether you merge your commits multiple times a day or once a day so long as you merge what you have so far and what you have so far is not a breaking commit (verified via automated testing)
    – zero
    Oct 30 '16 at 18:16
2

I don't think that you should change how you approach your tickets just because you are doing continuous integration, especially if your approach to managing tickets is working for you.

Although Grady Booch may have defined continuous integration as merging into a mainline multiple times in a day, I prefer to think of continuous integration as a set of good practices: having your code repository in version control, automating the build, integrating the build into your version control so you can have a pass/fail build on every commit, having automated testing, integrating automated testing into your build process, and making it easy to access the build. The only other thing to do is to keep your on-commit build process fast, but still providing useful feedback - depending on your system, you may not be able to run all tests at every commit and may need to defer some tests to a down-time (nights, weekends - times when the system can run for longer periods of time and the development team isn't waiting for the results).

Because you want feedback regularly, and you get your feedback from the build process, you do want to commit to the branches that get built and tested regularly. Often, this is talked about in terms of finishing a feature or fixing a bug. However, some features are larger. I don't think that a commit needs to entirely solve a problem. A commit could be performing some refactoring to support the implementation of a feature of bug fix. A commit could be adding additional unit tests (and any code to make them pass - you shouldn't break the builds) in preparation for code changes. A commit could be writing some new methods that are part of your feature, but may not be called yet (and for public methods, new unit tests to ensure they work). Or a commit could be the feature itself.

How you handle these intermediate commits before the feature is complete is up to you. My current team has a rule of thumb - work on a ticket that takes longer than 2 hours of heads-down time gets a subtask made. That may or may not work for you.

Focus on the good practices that benefit your team rather than how people have defined terms. Just because "continuous integration" has a certain definition that includes commiting multiple times a day doesn't mean you can't use and see a benefit from the other aspects of CI.

2
  • ah! I see. yeah that fits with the idea of agile being well...agile (and not fragile) and flexible enough to meet a group's needs how they (the group in question) sees fit.
    – zero
    Oct 30 '16 at 0:11
  • yeah, this clears it up quite nicely. Every source I read about CI seemed to imply that the "continuous" part was when things (tickets) were wrapped up and merged daily.
    – zero
    Oct 30 '16 at 0:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.