In CI, your code is deployed to the server with every change. That is, assuming your code does not break the tests that are written today.
This might sound natural at first when you consider a decade ago it was common to have someone live editing PHP scripts on a production server. Now we keep great version control of software. It's also been common to release new software updates in big batches monthly, quarterly, annually, or worse. Today, the problem with this approach is subtle bugs are discovered very late in the game, and as a rule of thumb, the bigger the set of changes is, the more likely bugs will be introduced.
CI is a reaction to these trends. We'd like to have the stability of running (and passing) our tests first before hitting prod, but we'd also like to not have release cycles be long. This allows us as developers with CI to roll out bug fixes and new features to production on a continuous basis.
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.
In CI, your code is deployed to the server with every change. That is, assuming your code does not break the tests that are written today.
This might sound natural at first when you consider a decade ago it was common to have someone live editing PHP scripts on a production server. Now we keep great version control of software. It's also been common to release new software updates in big batches monthly, quarterly, annually, or worse. Today, the problem with this approach is subtle bugs are discovered very late in the game, and as a rule of thumb, the bigger the set of changes is, the more likely bugs will be introduced.
CI is a reaction to these trends. We'd like to have the stability of running (and passing) our tests first before hitting prod, but we'd also like to not have release cycles be long. This allows us as developers with CI to roll out bug fixes and new features to production on a continuous basis.