The term build step is used everywhere, yet I searched both google.com and qwant.com to no avail. That baffles my mind.
I also searched for a developer terminology index. Anyone has a good explanation of this term?
DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.Sign up to join this community
In a CI/CD pipeline a build step is whatever you want it to be. It is the equivalent of a function or procedure from a traditional programming language. Examples of build steps from a CI/CD environment:
Notice that in the CI/CD world a build step is not necessarily building anything, but it might be preparing something to be built or doing something with an artifact of a build.
The precise answer will depend on the context in which build step is used. However, on a high level as per me, it is always relative to the deploy process. Build step is just before the deploy step.
Basically build involves making the application completely ready (compiling, linking, uploading artifacts etc or whatever is involved) so that we are good to go ahead and deploy it to webservers/containers that will eventually serve the requests
This gives a good overview, in my experience, build steps seem synonymous with deployment steps not just compiling code.
With all respect, but the previous 2 answers appear to me like misleading ...
In the big iron world, aka mainframe, the build step is often, though not always, a process that consists of at least 2 steps:
step 1 uses a program source, coded by a developer in whatever programming language (cobol, c, fortran, pl1, assembler, etc) as input, and then transforms that input in an object deck (which is not yet an executable ...). That transformation is typically done by a program called a "compiler" (each program language can have a zillion versions of such compiler, for cobol there is cobol vs, cobol le, cobol 2, and what not).
step 2 then uses the object deck (output from step1), to transform it into an executable program, e.g by staticically linking (called) sub-programs into it also. That transformation is typically done by a program called a "linker".
The complete set of compile-steps and link-steps is often bundled together in some sort of script (procedure), which in mainframe is often done via JCL (if compile/link is done in batch), or (eg) REXX (if compile/link is done online). And this script is actually what is called a "build procedure".
With the above in mind, go checkout any other OS where you also have compiles, links, etc. Sooner or later, you'll recognize similar compilers and linkers.
Attention: the result of such build procedure (an executable) is typically stored in some sort of work area (like a temp folder). And from there it still needs to be shipped (copied, FTPed, whatever) to somewhere else (e.g. an authorized folder or library), before it can actually be used to execute the executable (e.g. after appropriate approvals for an emergency fix have been gathered). That shipment process is what deployment of an executable is all about (as compared to building the executable).
And better not use that deployment target directly as output of your build procedure (if you do that, you basically open up your life environments to ... pretty much any developer, which is not what you want if you are a bank, or if your fixing some piece of software in a plane ... flying at 30.000 feet).