Best Practices to deal with frequent model
changes of long running processes
Webinar, 21st of March 2017
bernd.ruecker@camunda.com | halil.hancioglu@opitz-consulting.com

Todays speakers
Bernd Rücker
Co-Founder camunda
@berndruecker
bernd.ruecker@camunda.com
Halil Hancioglu
Senior Consultant
@ Opitz Consulting Deutschland
GmbH
@satspeedy
halil.hancioglu@opitz-consulting.com

The basic challenge with long running processes
Change
Long running flow
t

Versioning in Camunda
Version: 47
Version tag: „1.1.0“
Process definition id: 456-271-345
Version: 54
Version Tag: „1.2.0“
Process definition id: 911-081-577
ProcessInstanceId ProcessDefinitionId
123-456-789 456-271-345
123-456-790 456-271-345
123-456-791 911-081-577

Two basic options in real-life
Run in parallel Migrate to version

A look into our best practices

Agile development
https://www.linkedin.com/pulse/principles-agile-methods-used-business-management-graham-wood
Typically
short
iterations
Every
iteration
might
contain
changes
And
propably
set live

What do your ops think?
If you run hundreds of version in
parallel,
calling even multiple different
subprocess versions each,
I will kill you.
OK – great. We
appreciate clear
messages.
So let‘s migrate ☺

Migration

API

Cockpit
The migration plan can be
executed in batch or
downloaded as JSON.

Now let‘s get
serious!

© OPITZ CONSULTING 2017 Seite 13
Challenges in real-life project
 Automate it
 Identify Changes
 Do not miss any change
 Not mixing migration and production code
 Challenges of instance migration
Best Practices to deal with frequent model changes

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
“question” (CC-BY) by Mario Mancuso
Why do we need automation?

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Automate it
 Manual effort
 1 Process
 1 Change
per Process
 3 Environments
3 manual process migrations

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Automate it
 Manual effort
 5 Process
 2 Change
per Process
 4 Environments
40 manual process migrations

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
“CHANGE” (CC-BY-NC-ND) by Martin Deutsch
How do we identify process changes?

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Identify Changes
 For Example
 1 Environment
 2 Process Changes
 Engine detects
changes
 Create a new Process
Definition version
Deployment
sequence
Semantical
version
Camunda Process
Definition version
1 v1 v1
2 v2 v2

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Identify Changes
 And if we re-deploy?
 Detects only changes to
previous version
on each deployment
 Can’t guarantee the
semantical uniqueness
of a version
across multiple
environments
Deployment
sequence
Semantical version Camunda Process
Definition version
1 v1 v1
2 v2 v2
3 v1 v3
4 v2 v4
v1 v1
=

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Identify Changes
 Use Camunda VersionTag
 In Modeler „Properties Panel“

Idea! (CC-BY-ND) by Cristian Carrara

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Identify Changes
 Independent from
Definition Version
 Semantic Naming
Convention necessary
 E.g. Release & Sprint
Number, Git Hash, Git
Tag, Maven Version
 Change only on
relevant commit in
Master Branch

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
How do we ensure that we don't miss any Change?
„IMG_7181“ (CC-BY-NC-ND) by Dora Wu

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Don’t miss any Change
 For Example
 1 Team
 2 changes in a process
 During 1 Sprint
 Start with v1
 Change v1 to v2
PDCA (CC-BY) by Jurgen Appelo

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Don’t miss any Change
 Change v2 to v3
PDCA (CC-BY) by Jurgen Appelo

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Don’t miss any Change
 Document Change sequence
 Changes must be archived
 Migrate iteratively
every change
PDCA (CC-BY) by Jurgen Appelo

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Don’t miss any Change
 What if another
Teams modify
another processes
in same sprint?
 How can we
centralize
all changes
during a sprint?
Team A Invoice Process
Order ProcessTeam B

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Don’t miss any Change
 Archive changed model
in zip file
(local or remote)
 Create Migration Plan
for each change &
add Version Tag
 Link each archive and
migration plan in central
changelog file

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
How do we ensure that
migration is not mixed
with productive code?
“Think of a number.....” (CC-BY-NC-ND) by Mister G.C.

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Not mixing migration and production code
P = Production Code
M = Migration Code
Always
running
Runs only once on Deploy
or on Rlease

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
"310/366 - Fortbewegungsmittel / Vehicles" (CC-BY) by Boris Thaser
And More…
Camunda REST API is
not delivered and
therefore also no
migration API via REST
Execution without
Application Server
Administrators
intervention only in
exceptional cases
Central logging
(e.g., no mailing
of log files)
Containerizable
with Docker

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Not mixing migration and production code
 Setup a Migration Tool
with Spring Boot
 Parallel to the productive code
 Dockerized
 Automate execution with
CI/CD flow
 Central Logging
Interacts
or

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
“Signage 55 speed limit” (CC-BY) by David Lofink
Challenges of instance migration

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Challenges of instance migration
 Process needs further data for new
features
 Process variables must also be modified
 Instances could not be migrated
only with Camunda Migration API
 E.g. Modify an Event to a Task
 Use Camunda Modification API
“Restrictions” (CC-BY) by Davidlohr Bueso

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Challenges of instance migration
 Add “return points”
temporary as
process variable
 Can be defined
in so-called
modification
plans
 Modify & Migrate
to re-run
new added
validation
(Example)

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Demo

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Demo
 Approve Order
 Deploy Archive
 Local & Remote
 Logging in PaperTrail
 Start with v1
 Change v1 to v2
 Extend to reopen
rejected orders
 Notify only when reopened

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Demo
 Change v2 to v3
 Extend to validate
incoming orders

© OPITZ CONSULTING 2017 Seite 38
Conclusion
 Extendable Process Engine
 Flexible & well documented APIs
 Base for continuous improvement
 Automated Migration
 Benefit
 You don’t have to version the Sourcecode, because you’re
always on the latest process definition version
 @Camunda
 Extend Migration API and Modification API with
VersionTag and ProcessDefinitionKey
Best Practices to deal with frequent model changes

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
That’s it….Many Thanks!
Applause (CC-BY-NC-ND) by Kevin Labianco

© OPITZ CONSULTING 2017 Seite 40Best Practices to deal with frequent model changes
Q & A
You have Questions…
…We have Answers

© OPITZ CONSULTING 2017 Best Practices to deal with frequent model changes
Todays speakers
Bernd Rücker
Co-Founder camunda
@berndruecker
bernd.ruecker@camunda.comHalil Hancioglu
Senior Consultant
@ Opitz Consulting Deutschland
GmbH
@satspeedy
halil.hancioglu@opitz-consulting.com