The packages are deployed to our nexus server and distributed from there. 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.įinally, since we use maven and git, releases are managed by the standard git flow plugin.
Now it is time to package those single xml packages into a proper campaign package. Code review is intended to find mistakes overlooked in the initial development phase, improving the overall quality of the software. Since all packages are defined in their own file, we can actually do proper code review. After changes are reviewed and committed, pull request is finally opened. In case of a new entity, we can either use maven plugin or just put the manually exported package file into the appropriate directory. It is simple but effective, and it gives us the ability to track what has changed. If there is a difference (timestamp and author are ignored) between exported package and xml file, the file gets replaced. 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. So when a developer starts working on a new feature, a new git branch is created. Of course, everything lives in our git repository. Each subfolder will be built as a single campaign package xml file during build. As you see, the main parent module has many child modules based on different campaign types - schema, workflow, jssp, javascript and so on.
0 kommentar(er)
