Improve Adobe Campaign Development and Deployment Process

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:

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:

So how does our development cycle look like now? We have the following folder structure:

As you see, the main parent module has many child modules based on different campaign types - schema, workflow, jssp, javascript and so on. Each subfolder will be built as a single campaign package xml file during build.

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:

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

command and check the output for warnings and errors.

Going one step forward

Now we have packaging, release management and deployments improved. The next question is, how can we also improve development for Adobe Campaign? Writing javascript in client console is not ideal for developers who are used to a much higher standard nowadays.

In the folder, javascript packages are stored with `.js` extension. We take only the data part of the package and put the properties in the header comment section. This format is compatible with maven plugin so it gives us the possibility to use normal IDE and have features like auto-formatting, code completion etc.

Wouldn’t it be also nice if we could execute that javascript without using client console at all? We went one step forward and wrote a custom command line tool using Node.js. Using this tool, we can execute local javascript file on the AC server and print formatted results back. The best part of the new processes is that development speed has improved significantly as there is no need to restart workflows, refresh and check for output manually.

The tool can also do many other things like execute queries, import and generate mock data, upload resources etc., which makes our daily life much easier.

Lastly, we are considering opening our maven plugin and Adobe Campaign tools to the open source community.

Are all our problems solved? Not entirely. We have made great steps in the right direction and we will keep moving forward.

tag
Email Marketing
style
dark-plum