Join our largest event of the year | CamundaCon 2022 October 5-6

Icon Close
Register

For almost 10 years, JIRA has been our development issue tracker for the core components of Camunda Platform 7. About 15,000 tickets later, Camunda’s engineering has grown from one team to a team of teams. Many new projects have used GitHub exclusively as a code repository and an issue tracker from the start.

In October, we will move the CAM project to GitHub issues. With this change we are reducing the gap: our community can participate in our development processes with a single account. We achieve a unified approach for managing development issues, making it easier for everyone to participate.

We thank everyone who has contributed to our CAM issue tracker and hope that the collaboration continues in our new home. Find an FAQ with the details about this change below.

What is changing?

In the future, we will manage the issues for the Camunda Platform 7 core components in our central GitHub repository: https://github.com/camunda/camunda-bpm-platform

We plan to migrate open tickets with their comments from JIRA to GitHub. Our team will develop 7.19 and future 7.x versions exclusively on GitHub. GitHub labels will organize and group our issues. Have a sneak peek at our label glossary.

When does it happen?

Immediately after the 7.18 release, on the 12th of October 2022, we plan to start using our GitHub issue tracker. The migration of tickets will happen between 9 am and 6 pm CEST. There may be a short downtime during which you may not be able to create issues or write comments (CAM project only).

You may find that the GitHub issue tracker opens earlier as we are preparing the migration. We would like to ask you to keep working with the CAM JIRA project until the migration has been completed. Once GitHub issues are ready to use, we will publish an update in the blog, the user forum, and via email to our customers.

What happens with the CAM project?

At the time of migration, we will make the CAM JIRA project read-only and keep it publicly accessible. Links to CAM JIRA tickets or release notes will not change. Migrated CAM JIRA tickets will link to their corresponding counterpart on GitHub where the development and discussions continue.

Does anything change in enterprise customer support? Is the JIRA SUPPORT project affected?

Customer support does not change. As an enterprise customer you can continue raising support tickets in the SUPPORT project in JIRA. Wherever we previously communicated about CAM JIRA tickets, for example when fixing a bug, we will talk about GitHub issues in the future. In your SUPPORT tickets that link to an open CAM ticket we will automatically add a link to the corresponding GitHub issue.

Does anything change about how I can report security vulnerabilities to Camunda? Is the JIRA SEC project affected?

This process does not change. Wherever we will share an implementation ticket with you that addresses a vulnerability, it will be a GitHub issue instead of a CAM JIRA ticket.

Does anything change for the Optimize issue tracker? Is the JIRA OPT project affected?

We are considering migrating the OPT project to GitHub issues, too. We haven’t finally decided yet and this initiative is independent of migrating the CAM project. Stay tuned for news on this in the future.

Does anything change for Camunda Platform 8 projects, for example Zeebe?

No. These projects largely already use GitHub for issue management. By migrating the CAM project we are moving to what most of Camunda’s engineering works with.

How big was CAM JIRA?

  • Tickets created: 14,864
  • Tickets shipped in 7.x releases: 8,490
    • Bug Reports: 2,311
    • Feature Requests: 2,257
    • Tasks: 3,121
    • Sub tasks: 797
  • Users who created tickets: 895

  • Using FEEL with Camunda 8

    What is FEEL As a part of the Decision Model and Notation (DMN) specification, the OMG also defined the Friendly Enough Expression Language (FEEL).  Since DMN is intended to be used by designers and business analysts who would like to build decision tables, FEEL needed to be designed as an uncomplicated and human-readable expression language that would help readers understand the logic being described or executed by the DMN table.  Expression languages are typically used by developers to evaluate data to produce a result based on query parameters or conditions. This means it’s syntactically closer to code than human-readable sentences. Since one of the goals of FEEL is to be “process analyst friendly,” it prioritizes readability more than other expression...

    Read more
  • Camunda supports process automation at scale

    How Camunda 8 supports process automation at...

    Scaling process automation across an enterprise naturally includes a wide array of challenges. To counter these challenges, more and more organizations are evolving their organizational structures accordingly, often creating Centers of Excellence (CoE) and/or communities of practice (CoP). Please note that during this post we will use the term CoE, but keep in mind your organization might call this very differently. That said, in Camunda Platform 8, we included new functionalities that will help companies to scale process automation successfully.  This blog post discusses different aspects of scaling process automation, the role of CoEs, and how new Camunda 8 features support those initiatives.  What does scaling mean? Organizations that want to create a competitive edge through digital transformation (and frankly: which...

    Read more
  • 7 Best programming languages for microservices - Camunda

    7 Best Programming Languages for Microservices

    Microservices are an architectural style that structures an application as a collection of services that are: Highly maintainable and testable Loosely coupled Independently deployable Organized around business capabilities Owned by a small team Conway’s Law states that “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”. If your organization has multiple teams working on different parts of a larger system, then microservices can serve as a separation of concerns that map an independent, encapsulated service to a specific team. These teams have clear boundaries of responsibility and can deploy on their own schedule. These factors lend themselves to a polyglot approach. What this means is that because...

    Read more

Ready to get started?

Still have questions?