Adobe Campaign is a cross-channel marketing tool with some nice features to boast. However, the development and deployment process can be improved. Learn how.
Adobe Campaign is an Enterprise Cross Channel marketing tool that can do a lot of things very well - it is very flexible and extensible; it integrates with a variety of external sources; it supports many different channels, among other nice features.
Like many extremely flexible tools, the Adobe Campaign has its fair share of challenges. In our experience, one of the challenges faced is the management and deployment of packages. Sometimes during deployments, things got lost or were not installed, there were dependency errors in install logs, values got overwritten etc. The Netcentric team started to heavily investigate on how we could tackle these challenges. We have found an approach that improves our development and deployment process, and are constantly working on making it better.
Introducing Adobe Campaign Maven plugin
The first thing to make our life easier was to make our code packages cleaner and changes trackable. So we built a maven plugin. Since we already use maven in our AEM projects and jgitflow plugin for release management, going with custom maven plugin made sense. We were able to reuse the same soap calls as client console to communicate with the Campaign server in order to get what we need.
This custom maven plugin can do the following things:
Package multiple single xml packages into a grouped package with additional metadata
Export packages from the campaign server
So how does our development cycle look like now? We have the following folder structure:
│ │ pom.xml
│ │ cusRecipient.xml
│ │ cusDelivery.xml
│ │ ...
│ │ pom.xml
│ │ cusMyWorkflow.xml
│ │ pom.xml
│ │ subscriptionWithLanguage.js
... │ ...
Of course, everything lives in our git repository. So when a developer starts working on a new feature, a new git branch is created. After doing work on a local or dev campaign server, it is time to trigger the export feature of our plugin, which will go through xml files, connect to the campaign server and export entities with that name and type. If there is a difference (timestamp and author are ignored) between exported package and xml file, the file gets replaced. It is simple but effective, and it gives us the ability to track what has changed. In case of a new entity, we can either use maven plugin or just put the manually exported package file into the appropriate directory. After changes are reviewed and committed, pull request is finally opened.
Since all packages are defined in their own file, we can actually do proper code review. Code review is intended to find mistakes overlooked in the initial development phase, improving the overall quality of the software.
Now it is time to package those single xml packages into a proper campaign package. In addition to combining multiple files, the plugin will also write additional metadata to package spec - like version, branch and commit information, and list of included files.
Finally, since we use maven and git, releases are managed by the standard git flow plugin. The packages are deployed to our nexus server and distributed from there.
Deploying packages to Adobe Campaign
The requirements we have for deployment of Adobe Campaign packages are the following:
No dependencies to 3rd party or any non-standard tools.
Deployment should be done in a same way in all environments (from dev and test to production).
Ability to integrate with automation server such as Jenkins on non-client environments.
The last requirement is quite straightforward and easy to implement as there are several options to integrate with Jenkins. It is also important as it gives us the ability to deploy to our test servers automatically. Now our QA can select what (which hot fix, current development or release version) and where (to which environment) to deploy via Jenkins.
The first requirement limits us but this will always be the case in the real world - you are just not allowed to install any custom tools to client environments, especially a production one. Luckily Adobe Campaign supports installing packages via command line. So what we did is to write a bash script (we mostly work with linux-based installations) which iterates through campaign packages, triggers the installation using
nlserver package -instance:<instance> -import:<file> -verbose
command and check the output for warnings and errors.