Maven deploy plugin for Apigee & Apigee UI: how to avoid cases when changes are done via Apigee UI b

[optimism]

Hi!

Maven deploy plugin for Apigee & Apigee UI: how to avoid cases when changes are done via Apigee UI bypassing deploys via Maven+GitLab.

I'm using the Maven plugin for Apigee to deploy changes made in VS Code to the Apigee via GitLab.

At the same time, there are no restrictions visible to prevent making changes via Apigee UI.

So, there a possible real-world cases that could lead to confusion & mistakes:

• case a. I've made changes via Maven+GitLab+VS Code after some time made changes via Apigee UI & forgot about it - means my last changes are not in the GitLab. Then I made changes via Maven+GitLab+VS Code, meaning that previous changes via Apigee UI were lost between GitLab pushes.
• case b. My peer made changes via Maven+GitLab+VS Code, some time after I made changes via Apigee UI & forgot about it. No one are aware of my changes via Apigee UI & next changes are continuing with Maven+GitLab+VS Code, meaning my forgotten changes via Apigee UI are not in the GitLab.

How to avoid such two cases by preventing them from happening by a human factor(s)? Interested in engineering constraints & restrictions available on the Apigee side.

BR & thanks, 
Optimism 🙂 

[ssvaidyanathan]

HI @optimism (love the user id by the way 😀)

You are absolutely right about those use cases. This goes back to governance and tooling at the end. 

I would recommend tightly controlling the access to the Apigee environment(s). Open "dev" environment to all the developers so that they can build their proxies using VScode & UI and make sure they push all their changes to their Gitlab repo. And for the other environments, just provide access to your automation user so that anything pushed to those environments are ONLY using the pipeline.

With this you assure that no developer is making changes directly using the UI. And your source of truth is always your source code in the repo. You could argue that the above cases could happen in the dev environment. This is where your test framework and coverage comes handy. And if the developer misses to commit that code, its lost. This goes back to any application development, isn't it. Developers will need to follow some discipline but the process above only causes issues/conflicts in the dev environment which is better than someone changing it in the test, uat or prod environment.