Neptune DXP DevOps deployments

In addition to designing your architecture for productive use you also need to define a technical landscape to organize you DevOps activities:

devops1

A basic arrangement involves the deployment of:

  • Development environment to create your Neptune DXP artefacts (apps, server scripts, APIs etc.).

  • Quality assurance environment to test your artefacts.

  • Production for live operation use by your employees, partners, and customers.

Depending on your circumstances you may wish to enforce a strict separation of concerns by maintaining multiple development stacks for distinct target audiences. For example, you may wish to have 3 stacks of Neptune DXP environments catering to the individual needs of your:

  • B2E employee workforce, such as head-office and on-site colleagues.

  • B2B external partners, such as suppliers or wholesalers.

  • B2C customers, using Neptune DXP apps for transactions or to support enhanced user experiences.

By deploying Neptune DXP in a cloud setting you could also take advantage of the built-in auto-scaling capabilities to produce a performant and highly available landscape. Whilst this is typically a concern for production environments, you may also wish to extend this approach to your testing environments used for performance testing or staging environments used to verify your apps ahead of their productive release.

To facilitate a more varied landscape Neptune DXP allows you to assign a role to each Neptune DXP instance along with environment-specific role-based authorization models for accessing API resources. You can then use this to accommodate a comprehensive approach to developing, deploying and realizing apps and microservices:

devops2

Each environment is dedicated to a specific use case, such as:

  • Development (DEV) fixed environment or a disposable clone from a production environment where your developers are authorised to engineer new artefacts and validate them through the unit and/or consumer-driven-contract testing.

  • Integration (INT) post-deployment technical environment dedicated to the end-to-end verification of multiple Neptune DXP workloads and external systems.

  • Testing (TST) post-deployment environment used for performance verification (stress, spike, volume, load, scalability, endurance, soak testing).

  • Quality Assurance (QUA) post-deployment verification environment used by end-users for user acceptance and regression testing of existing functions.

  • Staging (STA) post-deployment environment used to gain operational confidence ahead of a product release; this may involve splitting or shadowing production traffic to verify its operation.

  • Production (PRD) environment released for operational use. At release time you may want to execute a progressive rollout pattern using feature flagging, traffic shaping, canaries and monitoring whereas after an initial warranty period the focus shifts on observability with active monitoring of logs, tracing, metrics, alerts being the primary concern.

  • Sandbox (SAN) disposable clones of a Production environment used for evaluation or post-release verifications (for example, trial instances, or transient clones continuous testing).

  • Local (LOC) personal evaluation copies or relabeled environments ready for decommissioning, for example, broken INT, TST, QUA, STA test instances or obsolete/outgoing PRD versions.

The above setup requires the ability to transfer artefacts between environments. Typically, that requires the use of a CI/CD framework (for example, Jenkins) managed as a separate entity to your development environment. Neptune DXP provides an in-built DevOps pipeline mechanism that allows you to easily and securely transfer all your Neptune DXP artefacts between Neptune DXP workloads. The example below shows a pipeline supported your Neptune DXP roles to implement 3-step approval driven workflow that controls the propagation of artefact from Development through Test and then on to Production environment:

devops3

You can implement the above process to:

  • package your artefacts so that all dependent elements move along the pipeline at the same time

  • pre-define deployment routes for clear integration and deployment paths, and

  • implement role-based security authorization for the request, approval and transfer of packages.