API Lifecycle Management, CI/CD for Microsoft shops

[Former Community Member]

Coming from a Java background, I am used to several CI/CD, version management, automation tools like git, subversion, maven, Jenkins etc. There is also a lot of articles/frameworks on how to plug API Management into these tools.

Have heard about tools like PowerShell, Team Foundation Server, just curious how existing Apigee Edge customers who happen to be Microsoft shops are tackling API Lifecycle Management, versioning, CI/CD? Please share your insights/experiences.

[Former Community Member]

Great community article by @Dino on this topic. Any others??

[dcouldwell]

@Kurt Kanaskie anything you can add on this?

[kurtkanaskie]

@Prithpal Bhogill On my last project I used Team Foundation Server with Jenkins, Maven and Apickli/Cucumberjs all in a Microsoft shop.

For TFS with Jenkins, installed on its own VM, we polled the repositories, but I think I saw someplace a way to have builds triggered. We did not automate downstream environment builds, the team did manual deployments from the main DEV to the downstream QA, UAT and PROD environments.

Each developer had their own dedicated VM connected to TFS via Visual Studio. We used feature branches with replacements by user for proxy basepath for parallel development, as per the Apigee Maven Plugin usage. However, we had to set up separate developer build projects in Jenkins because we could not get Jenkins to poll for wild card features branches (branches under the feature folder in TFS). So each developer had their own build project (e.g. proxy-username-v1) in Jenkins that polled their specific feature branch that was reused for each feature they worked on. Not the best but manageable. The developers just had to merge from the Main DEV to their feature branch to sync up before starting their work.

Since TFS did not provide GitHub style build information, we used replacements in the "apiproxy/proxy-v1.xml" file to hold the build information:

In proxy-v1.xml we use the "@BUILDINFO" tag along with manually entered text in the description:

<APIProxy revision="3" name="proxy-v1">
    <Description>@BUILDINFO JIRA-477 new feature description</Description>

Then in the pom.xml

<properties>
        ...
        <tfs.changeset>TFS_CHANGESET</tfs.changeset>
        <build.tag>BUILD_TAG</build.tag>
</properties>
...

<replacements>
        <replacement>
             <token>@BUILDINFO</token>
             <value>${tfs.changeset} ${build.tag} ===</value>
        </replacement>

And finally in the Jenkins build project:

mvn -P dev install -Dtfs.changeset=${TFS_CHANGESET} -Dbuild.tag=${BUILD_TAG} -DtestType=@intg

We also used GitBash on the developer MS VMs.

For Apickli/cucumber we needed to install as:

npm install -g cucumberjs (installs command line tools per OS (e.g. cucumberjs)

The project had 3 dedicated API developers working on 3 separate API proxies. We also got the QA test team to use TFS and Apickli/Cucumber to build out the tests.

Hope that helps,