In my company, I'm currently working on a project with some (REST) web services involved. The development is based on the OpenAPI specification and the Swagger tooling. The target platform is an internal cloud platform based on OpenShift.

As we make use of an CI/CD pipeline in our software development process (more or less the whole Atlassian Toolchain, Artifactory, etc) the question rises whether is possible to neatly integrate a code generation step in the pipeline.

The API development process right now is basically like this:

  • Write / Modify API specification
  • Commit changes into SCM
  • Validate spec and generate API documentation

The process to develop (e.g. the server) against the API spec is like this:

  • Local generation / update of server stubs
  • Commit into SCM
  • Server code is then implemented against the generated and checked in stubs

The question is, whether this is the go to solution to work with a code generator in general. I have the subtle feeling that the local generation of code is not the best solution here, as one have to update the SCM on a regular basis with newly generated stubs to be up to date with changes in the API specification.

One idea that came in to my mind is to make e.g. use of an artifact repository manager (like Artifactory). The build process could then create a server stubs library based on the API spec which is pushed into the artifact manager. Developers can than make use of their local build system to update the dependency. However, this process might be an overkill.

As I could not find good resources about the integration of code generators in a software development process using CI/CD pipelines, I'm very interested in best practices here (or maybe there is a good specific solution for my previously described example?).

  • 1
    You haven't told us what your criteria for "best" is, or what problem you're trying to solve. "Best practice" doesn't quite cut it. Commented May 16, 2018 at 17:02
  • 1
    Central point of my post was the question if code-generation is usually a "local" step. To be more precisely: Should the local build environment of a developer be responsible to do code generation? Furthermore, should generated code be part of the project's code repository or is there a benefit including generated code as a separated dependency (so that generated code is not part of the code repository). My criteria for "best" are basically a clean code-repository structure and a simple build infrastructure. Developers should have minimal contact with the code generation process. Commented May 17, 2018 at 8:11
  • I’ve always automated the generation as part of the build process. This should be run the same locally as it does on the CI server. How you do that will depend on the lang you’re generating.
    – RubberDuck
    Commented May 17, 2018 at 20:55

1 Answer 1


Should the local build environment of a developer be responsible to do code generation?

Yes. Where else would you do it? If you don't do it there, your program won't run properly in the IDE. If your program doesn't run properly in the IDE, you can't test and debug it locally.

As an example, we use Fody.PropertyChanged to code-generate an INotifyPropertyChanged implementation for our View Model classes. The code generation is kicked off as part of the IDE's build process.

Our build server repeats this code generation process when it does its build and tests.

Should generated code be part of the project's code repository?

No. You didn't write it. The purpose of a code repository is to store, maintain and keep track of code that you write. Code that is generated from a tool is not interesting in this way. Code that generates code might be.

We don't store the code that Fody generates, because the whole point of that code generation is to abstract away those details. The [AddINotifyPropertyChangedInterface] attribute that triggers this code generation is stored in source control instead.

Assuming that the generated code "takes care of itself" there is no need to store it in source control, but there are exceptions. For example, you might still store SQL scripts that you generated from a tool such as Sql Server Management Studio in the code repository, if you don't have an automated step that synchronizes database changes for you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.