Deploying APIs using Jenkins and Apigee maven Plugin

There are multiple ways to achieve this depending on the level of auditability and RBAC you want to enforce in deploying these proxies(within Jenkins).

If you had a single Job, and you wanted to restrict certain people from deploying certain proxies - there is no way you can control that in Jenkins unless you build additional custom controls (AFAIK). You could

• enhance the job asking the user to provide deployment credentials (rather than using accounts implicitly)
• have different deployment accounts for different environments in Apigee and enforce it that way.

If RBAC for deployments isn't a concern for you and you store your proxies in a git repository (each proxy in its own repository)

Your first step of the Jenkins job should be to clone/checkout the proxy repository. You can add a job parameter to ask the user to provide that repo url. If you are using Git, you can also pull down a list of proxy repositories and ask the user to pick from the list(explore invoking your SCM's REST API's from Jenkins to pull a list of repositories and filtering down the list based on naming patterns)

When the repository you clone is selected dynamically , you can now reuse the existing job without making edits to its configuration.

If you were trying to deploy multiple proxies with a single click, you could allow the user to select a list of proxy repositories, use bash to iterate over the list of repos and invoke the maven plugins, this however is a flawed implementation because your job outcome now depends on deployment outcome of multiple proxies. Jenkins job will fail on first failure detection, so some proxies might end up being deployed even if the job has failed

HTH

Hi

There is a concept of multiple modules in Maven where you can build many modules. You just need to declare them in your parent pom and that can trickle down to each child project. More info here.

You just need to declare a parent workspace and place all the proxy folders within that have their individual pom files. The parent folder pom can just be as simple as

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>


    <groupId>apigee</groupId>
    <artifactId>proxy-parent</artifactId>
    <packaging>pom</packaging>
    <version>1.0</version>
    <name>Multi proxy Parent Project</name>


    <modules>
        <module>apigee-proxy1</module>
        <module>apigee-proxy2</module>
    </modules>


    <build>
        <pluginManagement/>
    </build>
</project>

The modules are the proxy folder that have their own pom files. If you have anything common that can be shared within these sub-modules, you can define them in the parent pom

Regarding best practice in Jenkins - you can have individual jobs or if you use Jenkins 2.x (Pipeline jobs), you can use the same Jenkins build file and connect to your repository through hooks so that they automatically trigger.

As @rmishra mentioned in his answer above, there are different solutions and recommendations around that. Its tightly aligned to your SDLC and release management processes your company follows.

Hope this helps !!