Looks like a smart hack to deploy to production on every commit, but while it gives the illusion of continuous delivery, it is actually a terrible idea since there is nothing to catch a regression before it goes to production.
In the Java world is common to use tools like Jenkins for your continuous delivery pipeline. You can have a Jenkins job triggered by a Pull Request, so you can validate the build passes and perform code reviews. Then you can have another hook for merging the PR which can perform additional integration tests, stress tests etc and deploy to artifactory (or other), and if everything passes you can finally deploy to production.
Doing it like this does not mean you dont have that. In fact we use Gitlab as our `origin` that connects to a CI and allows code reviews. Some other projects of mine use Github for the same. This is really just about deploying itself.
2 comments
[ 2.0 ms ] story [ 15.4 ms ] threadIn the Java world is common to use tools like Jenkins for your continuous delivery pipeline. You can have a Jenkins job triggered by a Pull Request, so you can validate the build passes and perform code reviews. Then you can have another hook for merging the PR which can perform additional integration tests, stress tests etc and deploy to artifactory (or other), and if everything passes you can finally deploy to production.
I dont see the conflict honestly :)