Are creating build artifacts, running test cases and deploying, the 3 main parts of CICD

CICD can have multiple steps in the pipeline but broadly are creating the build artifacts, running test cases and deploying the build artifacts, typically the 3 main parts of CICD pipeline ? Thanks

Does it matter how anybody chooses to classify parts of a pipeline?

We have Jenkins pipeline in our project. I too push changes to our repo and run programs after those deploy but Jenkins pipeline has been a Blackbox for me. So instead of continuing to remain confused about what it does I thought of breaking what it does into parts. Although I don't know it fully, what I have understood far is that broadly it is doing 3 things for us: running test cases and if the test cases pass creates the build artifacts and then deploy it to cloud (using spinnaker).

Jenkins is an extremely powerful and flexible system. It can trigger builds off source code commits, and those builds can run tests and generate test reports to be posted to a project status website. It can also deploy directly in many cases, or feed to downstream provisioners as you desire.

Jenkins can do a lot of its magic directly, but it also leverages the tools it controls. For example, if a Maven build includes the "test" goal, that's what causes the tests to be run using the test runner Maven plugin and can cause them to be summarized and reported via the surefire-reports plugin.

It used to be that you could actually see a lot of this stuff for Apache projects, but I can't find any of it in public view these days.

Honestly, there is no way for us to classify your pipeline for you. Every pipeline is as different as the project itself and the team that set it up.

The only thing I can tell you for sure is that the pipeline first builds, then deploys.

Testing the software can be done as part of the build by the build tool, or it can be a separate step in the CI pipeline, or it can even be done at the very end after the software has been deployed, or any combination of the above. It completely depends on the team philosophy and on the project requirements.

If you want to understand your project's CI/CD pipeline, you should schedule a meeting with your team's DevOps engineer.

Tim Holloway wrote:

Jenkins can do a lot of its magic directly, but it also leverages the tools it controls. For example, if a Maven build includes the "test" goal, that's what causes the tests to be run using the test runner Maven plugin and can cause them to be summarized and reported via the surefire-reports plugin.

Thanks. I understood this now.

Stephan van Hulst wrote:
The only thing I can tell you for sure is that the pipeline first builds, then deploys.

But isn't that the only possible obvious order as you need to first build something in order to deploy it?

Stephan van Hulst wrote:

Testing the software can be done as part of the build by the build tool, or it can be a separate step in the CI pipeline, or it can even be done at the very end after the software has been deployed, or any combination of the above. It completely depends on the team philosophy and on the project requirements.

But if testing is done at the very end after the software has been deployed, then is it not a waste in some cases to even proceed if the test cases fail?
If the test cases fail, then shouldn't, it be not allowed to proceed to deploy and this should be the obvious order?

Monica Shiralkar wrote:But isn't that the only possible obvious order as you need to first build something in order to deploy it?

Which is why I told you it's the only thing I can tell you for sure.

But if testing is done at the very end after the software has been deployed, then is it not a waste in some cases to even proceed if the test cases fail?

In some cases yes. For instance, unit tests should happen before deployment. But note that I said that the pipeline can contain a combination of tests. Why should unit tests be the only kinds of tests I want the pipeline to execute?

If the test cases fail, then shouldn't, it be not allowed to proceed to deploy and this should be the obvious order?

What about GUI tests? Those can only be performed after the application has been deployed.

Stephan van Hulst wrote:
What about GUI tests? Those can only be performed after the application has been deployed.

Not at all.  That's what systems like Selenium are for.

Doesn't Selenium just test what appears in the browser? Doesn't the application at least need to be deployed on a test server for that?

Stephan van Hulst wrote:Doesn't Selenium just test what appears in the browser? Doesn't the application at least need to be deployed on a test server for that?

I believe so. Although I've been reading up on Spring Integration Testing and I think it can maybe cover some of that.

One problem is that a lot of modern web GUIs need both a remote JavaScript engine and at least some simulation of host logic to respond. Selenium itself can likely fake out the client-side stuff, since it's in JavaScript anyway, but you'd still need to emulate a server. Which, I suppose is possible. Ah, I really don't know what I'm talking about here. I'd have to go refresh my Selenium know-how. But it's possible.

Spring Boot can likely do more, since Spring Boot contains its own servet/JSP engine anyhow. A GUI like Swing, of course, has its own testing needs.

As a rule, I do most of my application logic in business beans, which can simply be unit-tested. When I really need to test a GUI, it's likely to be as part of testing an entire workflow.