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).
