> Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now.
That's in a "Best Practices" section with this note at the top:
> This section contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity, Wikibooks or Wikivoyage. (May 2015)
I'm not an expert, and I've read no books on the subject, so I'll refrain from suggesting sources. The implication of my comment was that it's disingenuous to use that link as proof when it's marked with the equivalent of a FIXME.
First off, I have no motive to be disingenuous. I really don't care how you collaborate on software with your team.
Secondly, CI itself is considered a best practice. I don't know how you could expect wikipedia to mark it as anything else?
Here's the top link from google if you really care to learn and aren't just here to be a contrarian: https://www.thoughtworks.com/continuous-integration . There is a wealth of information on this subject that I promise all says the same thing. We can argue about whether or not CI is useful, but the practice of integrating continuously is in all the literature as well as the name itself.
Obviously if you can't break it up into smaller pieces, you can't regularly integrate smaller pieces. That's a tautology.
With that said, I've been doing this for over ten years and haven't come across that scenario. You can easily figure out all kinds of tricks to break things down, but usually only after you believe in the value of it.
You try by testing. Take big software like Firefox as an example. There are hundreds of commits landing on a good day and to merged into moz central you need to submit the patch for review and testing. Once the code is merged there are more testing and if something broke along the way the release team will figure out ans backout the bad commits or get someone add a fix asap. It is important to not be afraid to merge but also be responsible for your code. Take major refactoring as an example - don't create a patch which is partially implemented with breakage. You can ask for review but don't request a merge knowing it will break - actually your tests should tell you that. Finally, it is important to communicate changes regularly. Developers shouldn't be suprised to see their changes broken because someone else decised to refactor all the sudden.
I understand that testing tells you you broke the trunk, so you didn't break up the feature into small enough merge-able pieces. My question is what happens if you can't break it up any smaller--do you just throw up your hands and say you can't implement the feature because there's no way to break it up into small enough pieces?
You can bulk delete a bunch of functions and won't break anything. Your patch may require changes to 30 files but the change is minor. "Small enough pieces" is ambiguous I admit. I think a better way to put it to work is make your patch enough to get your code reviewed. If there are drastic changes, just let people know what you are planning to change (really, write out your plan). You may have to write wrappers or keeping the original function intact but write a my_api_function_2 for the newer version so people can start adopting it.
Quite true actually! : https://en.wikipedia.org/wiki/Continuous_integration#Everyon...