-1

My customer decided to have an automatic nightly build based on develop branch.

We usually make a feature branch (and if it is necessary we provide a release compiled manually on that branch) and when work is done we make a pull request (to develop branch)

The customer complained that the nightly build does not include anything about the feature that is still in progress, but we don't want to merge code without a pull request.

I cannot figure out how to structure this process. Is there a clever way to set our CI?

Improve this question
5
  • 1
    Work on smaller features, merge them earlier, but guard them behind feature toggles so that they can be tested? This is how web browsers do it. Commented Dec 23, 2021 at 10:04
  • the artifact is a mobile app. the problem is that we do not have enough time to write down code make PR, merge PR, etc. Commented Dec 23, 2021 at 10:08
  • 1
    What do you mean by "that the nightly build does not include anything about the feature that is still in progress"? If the feature is still in progress, why would it be in the nightly build? I'm assuming the nightly build is built from the develop branch, not the feature branch? Commented Dec 23, 2021 at 10:12
  • 3
    Why is your customer dictating your process? Why do they care if you have a nightly build or not or what branch(es) are built? Commented Dec 23, 2021 at 10:50
  • 1
    "I cannot figure out how to structure this process" - not sure I understand where the problem is. You can surely configure the branch from which your CI creates a build. You can surely configure more than one individual project for your CI to be processed at night. And you can surely run two different builds at different times (as long as the build time does not require more than half the night, otherwise you could do it on two servers in parallel). So by simply treating the two branches as two independent projects, where is the problem? Please edit the question and clarify. Commented Dec 23, 2021 at 12:36

2 Answers 2

Reset to default
3

It depends on how long it takes your full build/test cycle to complete.

Nightly builds make sense if the full build/test cycle takes more than minutes to complete. If your test cycle takes a few minutes or less, you can probably run all of the tests on all of the branches after every commit. There are plenty of valid reasons for a full test cycle to take more than a few minutes, especially once you start including integration and system tests that have additional dependencies or test timing requirements.

Given this, one option would be to run the nightly build on all branches.

However, that doesn't necessarily make sense. In a workflow like gitflow, feature branches are often work in progress. If work takes more than a day, work could be committed into a feature branch that is incomplete. The incompleteness could cause failing tests or it could be related to a lack of test coverage of the new feature, resulting in false failing or false passing tests. These false indicators don't add much value.

Another option could be to significantly reduce the scope of feature branches, using techniques like feature toggles or keystone interfaces, which would allow you to integrate your work into the develop branch (or even deploy) while hiding the work. The two can be combined by having the feature enabled in the feature branch, but not merging the enabled feature flag or keystone interface until after the feature branch is done and enabled. You would need to account for ensuring test coverage as you develop the feature, and perhaps even enable the feature flag during your CI builds and tests.

Ultimately, though, I would push back on why your customer wants to be so hands-on with your development process. I'd figure out why they care about your builds, which are primarily for developer feedback. If they have questions or concerns, there may be better ways address those than changing your workflow to run nightly builds on work-in-progress.

Improve this answer
3
  • I think this answer makes a questionable assumption: that the nightly build run includes a full test suite, and if that's the case, that the nightly build for a feature branch must run the whole set of tests as the dev branch. But a nightly build has also a more basic purpose: to make sure the whole system compiles (for example, noone forgot to add locally added files to version controls). This makes a lot of sense even for unfinished feature branches. Commented Dec 23, 2021 at 12:29
  • @DocBrown The question talks about CI and is tagged with continuous-integration. Running tests are a key aspect of CI. If you aren't running tests, you aren't doing CI and are just doing builds. Commented Dec 24, 2021 at 17:25
  • I don't deny this, nevertheless there are different flavors how CI can be implemented or configured, One approach might be to include all the tests for the nightly build of the dev branch, but only fewer (or no) tests for the nightly build of a feature branch. It all depends on the goals of the OP, which aren't really clear. Commented Dec 24, 2021 at 19:41
0

It seems like a misconception on the part of the customer about the purpose of nightly builds.

Nightly builds are not for checking your feature builds ok. They are checking the build process hasn't broken due to problems unrelated to the code. ie OS update and the like.

Or if you are doing trunk based dev and only compiling portions of the solution when code is checked in, you need that full build on a regular basis.

From the way you speak about your process I imagine you are only working on one feature at a time? or finishing features on a weekly rather than daily basis?

This is quite slow, I would want to see a feature a day being checked in, just to keep track of sprint progress, even if the feature took a few days to program. I imagine this is why your customer is complaining. They are concerned that they can't see progress.

If you have these long gaps between completing features you should work out why and possibly change your process.

If its just one feature at a time, you can just push changes to dev instead of a feature branch.

If its big features that take ages to finish, you should prob break them down into shorter features.

Improve this answer
3
  • "It seems like a misconception on the part of the customer about the purpose of nightly builds." - sorry, but I disagree. It can be perfectly reasonable to expect a nightly build to validate more than one branch. Moreover, your idea of how feature branches should be used is surely one possible way, but not the only reasonable way. Commented Dec 23, 2021 at 12:20
  • builds to validate code are done on check in. so a nightly build has no code change from the last build, regardless of branch, and hence cant be to validate code. (exceptions noted in answer) Commented Dec 23, 2021 at 13:04
  • Also, as you know i do prefer an opinionated answer over one that covers every possible opinion as I feel those dont actually give you a usable answer. Commented Dec 23, 2021 at 13:06

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.