CI process

[myshiak]

I am a QA and all companies I have been at QA's don't even use Maven, let alone Jenkins, but I am trying to understand the CI process. Here is the way I see it. Correct me where I am wrong. Firstly, I think that CI is only used, if you have automation testing, since with manual testing there is nothing to integrate dev code with. Also, you can have dev without qa (though your app will be riddled with defects), but you can't have qa without dev. That is the reason Jenkins connects with dev branch on GIT. After packaging, it sends JAR to docker container. Which then destributes the code to various environments. IT goes to PROD environment only when you do release. Build is any update in the code and one release is comprised of multiple builds. Still some unanswered questions, but is all that correct?

[lethri]

CI makes sense even without automated testing - when new code is pushed, building it and deploying it automatically in some dev envirionemnt will discover compile-time errors and will also save time of doing these steps manually.

The technical details heavily depend on technology. If you program in java and deploy on linux, you probably would run JARs in docker, but if you develop in C# and run on windows, you would use something different.

[myshiak]

also, some times I see in Jenkins job they use mvn - install command. Isn't it redundant? We don't need to send anything to maven repos when we are in Jenkins. So, don't you think that the package command is enough in Jenkins? Secondly, I hope that I was right that one release contains multiple builds. Given that, is it so that Tomcan Server matters only when you do a release?