Continuous integration is usually but not necessarily automated (I've used Jenkins or Gitlab to automate) and in essence is the integration of the master code into your changes (not the other way around) at a high frequency, which usually is on every commit in Gitlab or can be time or commit quantity based in Jenkins. This high frequency continuous integration of the master branch into your code tests that when your code is integrated into master then master will still compile and pass any unit and / or integration tests depending on your CI tool setup.
Continuous deployment is then the follow on factor of CI, if all is good and master is still compiling and passing tests to show it is performing as expected then the new version of master with your changes integrated can be deployed to allow your customers (whether that just be other Devs on your team or actual customers) such that any bugs are fixed for them, or requested features are provided. Agile sprints essentially provide a continuous (usually 2 weekly) deployment.
Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
is the integration of the master code into your changes (not the other way around) at a high frequency
That's interesting. Your comment led me to look up the origins of the term. It seems like Booch and the other XPers specifically advocate merging working copies into the main line daily, but I agree that it's more useful to just make sure that working copies remain in a state where they're ready to be -- so, given distributed version control, to have master merged in often.
I'm sure the hardcore agilists would say that you shouldn't end up with something that's not ready to merge in the first place, since you're fully TDD / YAGNI / etc., but IME there may be good reasons to wait until something's fully baked (schema changes come to mind).
FWIW my preferred thing is for PRs to be small, but self-contained -- i.e. as simple as possible but no simpler.
I agree. I simply meant you want to ensure the integration of your code and master will not cause master to faulter so safer to merge out to you than in to master until stability is confirmed
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Continuous integration is usually but not necessarily automated (I've used Jenkins or Gitlab to automate) and in essence is the integration of the master code into your changes (not the other way around) at a high frequency, which usually is on every commit in Gitlab or can be time or commit quantity based in Jenkins. This high frequency continuous integration of the master branch into your code tests that when your code is integrated into master then master will still compile and pass any unit and / or integration tests depending on your CI tool setup.
Continuous deployment is then the follow on factor of CI, if all is good and master is still compiling and passing tests to show it is performing as expected then the new version of master with your changes integrated can be deployed to allow your customers (whether that just be other Devs on your team or actual customers) such that any bugs are fixed for them, or requested features are provided. Agile sprints essentially provide a continuous (usually 2 weekly) deployment.
That's interesting. Your comment led me to look up the origins of the term. It seems like Booch and the other XPers specifically advocate merging working copies into the main line daily, but I agree that it's more useful to just make sure that working copies remain in a state where they're ready to be -- so, given distributed version control, to have master merged in often.
I'm sure the hardcore agilists would say that you shouldn't end up with something that's not ready to merge in the first place, since you're fully TDD / YAGNI / etc., but IME there may be good reasons to wait until something's fully baked (schema changes come to mind).
FWIW my preferred thing is for PRs to be small, but self-contained -- i.e. as simple as possible but no simpler.
I agree. I simply meant you want to ensure the integration of your code and master will not cause master to faulter so safer to merge out to you than in to master until stability is confirmed