Everyday Delivery

The prior Stages have built and validated a set of incremental updates that deliver value to your users. The update can be based on specific feature/set of features which can be deployed independently without a need to connect it to a specific sprint deadline or other formal milestones. This is also supported by a high degree of automation within the No-code platform for Governance and Continuous Deployment. Taken together this allows for quick, small updates to be pushed frequently (perhaps daily), to production while maintaining higher levels of quality than traditional ‘big bang’ software releases.

The intent of this stage – Everyday Delivery – is to enable rapid updates to the end user and maintain a high velocity, ongoing improvement cycle. This chapter will discuss some of the key tenets that should be adopted in your no-code development to support this rapid cadence of releases. Refer to the supporting material around both the key Roles and Responsibilities and Application Matrix which will be referenced throughout the guidance.

The outcome of this stage should be a set of high-quality feature updates that have been released to production for your no-code app, along with the process and infrastructure to rapidly deploy and rollback as frequently as needed.

The inputs from the MVP Go-Live release and the feedback collected from stakeholders and feedback channels will form the key inputs into this current effort. Here are a set of key pre-requisites you should make sure are in place before starting this stage.

• Application MVP deployed to production.

• Feedback collection (user & system) processes in place.

• Continuing support from IT/Ops for Governance reviews and updates.

• Continuing Change Management and Backlog processes in place.

• Continuing Testing approach and resources (e.g. manual, automation, etc).

• Continuing Work management processes (e.g. Kanban) in place.

The work in this stage will be mostly focused on a discussion around architecture and design tenets. The No-code architect will have a large role to play in helping enable the activities. If a CoE exists, they will likely also have taken a lead role in establishing the process and tools necessary to enable this Everyday Delivery model.

Loose coupling means the solution is structured in a way where there are modules with known boundaries and different business domains that can be enhanced and evolved independently. This can be achieved with the composable application approach where one solution is divided into a set of distinct business applications that may be reused, reconfigured, and redeployed in isolation from other components. Gartner research shows that adopting the composable approach in application design assures you're prepared for accelerated change delivery.

No-code platforms are well-suited for achieving loose coupling via this type of composable architecture. Here's how no-code platforms can support this approach:

• Modular design: The no-code platform enables the creation of modular components that can be easily combined and connected. These components can represent specific functionality, user interfaces, or data processing tasks. By designing components with clear boundaries and well-defined interfaces, you can assemble them in a composable manner. They can also be shared and reused broadly from the Marketplace.

• Visual composition: No-code tools offer visual drag-and-drop functionality, allowing users to visually arrange and connect components. This visual composition approach aligns well with the composable architecture, as it facilitates the arrangement of different components and the establishment of connections between them.

• Reusability: No-code tools can encourage the creation of reusable components. By designing components to be self-contained and reusable, you can easily compose them into larger systems. This reusability promotes modularity and allows for efficient composition of components to build more complex applications.

• Built-in integrations: Leading no-code vendors provides a broad set of built-in integration via external services, APIs, and databases, and also pre-built third-party integrations via the Marketplace. These integrations can be leveraged to compose and connect components with external systems, enabling the construction of composable architectures that interact with various external resources.

• Event-driven capabilities: Leading no-code vendors may support event-driven mechanisms, thru triggers and workflows. These mechanisms enable components to communicate and interact through events, making it easier to compose different components in response to specific events or actions.

This type of loosely coupled approach is important regardless of the complexity of your application. However, there are some differences in the areas of focus you should have depending on the Delivery Model you have chosen for your app.

DIY Delivery Model

In simpler apps, the key result we want to achieve with loose coupling is to allow multiple people to work on application logic without disrupting each other with conflicting changes. To achieve this, learn your no-code platform capabilities for structuring business functionality. Choose different modules or packages to separate business logic. If one part is likely to be updated independently of the other, put them in two distinct packages. Know your domain well to create an object model where each object may be updated independently. Break down your business process into modular sub-processes based on functionality or workflows. Each sub-process should have a specific purpose or task, making it easier to maintain and update independently. For example, a business process of more than 10 steps or more than 3 alternative flows is hard to read, understand and maintain; so decompose it to a set of subprocesses each of which may be updated independently. Leverage built-in integrations capability to connect with various services via REST APIs or integrate with Databases. Utilize these integrations to interact with external systems or fetch data. By relying on these simple built-in integrations, you can keep the components loosely coupled from external dependencies.

CoE or Fusion Team Delivery Models

As your no-code app increases in complexity, you should formalize the use of a composable application approach to introduce agility into your application. We recommend using domain-driven design (DDD) practices to decompose your business application: By business roles: Each role automation is done in a different composable app; By department: different workflows belong to different composable apps; By integration points: each integration lives in a different composable app, e.g. an app for external calendars sync, digital ads platform integration, or lead generation from social platforms. Review the domain objects in your application data model for abstraction and reuse. Use data modeling techniques to define and structure your data to create reusable data models or schemas that can be shared across multiple components. This helps decouple the data structures from individual components. Your no-code vendor will probably offer a selection of pre-built integrations with external services or APIs via a Marketplace. Utilize these integrations to handle complex functionalities or specific requirements without tightly coupling them to your application's core components. Identify common or reusable logic within your application and encapsulate it within separate components or functions. This allows you to reuse the same logic across multiple areas of your application without tightly coupling it to specific components. As your no-code application evolves, periodically review the design and dependencies between components. Refactor and optimize the application structure to ensure loose coupling is maintained as new features or changes are introduced.

By using these practices to implement Loose Coupling in your no-code app, the no-code platform can serve as a powerful tool for achieving a composable architecture by enabling the modular design, visual composition, reusability, integrations, and event-driven capabilities that facilitate composing and connecting independent components.

Change isolation refers to the ability to make modifications or updates to one part of the system without impacting other parts. It involves structuring the system in a way that minimizes the ripple effects of changes, allowing for greater flexibility, maintainability, and scalability. It also means you develop increments to the functionality as independent streams of work and use proper branching models to ensure each complete feature can be verified and deployed independently when ready.

No-code platforms can support effective change isolation. Here's how no-code platforms typically support this approach:

• Clear Interfaces and Contracts: Define clear interfaces and contracts between components. Components should communicate with each other through well-defined interfaces, specifying the expected inputs, outputs, and behavior. This ensures changes to one component do not break the contract or assumptions made by other components.

• Dependency Management: Understand and manage dependencies between components. Minimize dependencies between components to reduce the impact of changes. When components rely on external services, APIs, or data sources, use abstraction layers or adapters to decouple them, allowing for easier substitution or modification of those dependencies.

• Versioning and Release Management: Implement versioning and release management practices to control and isolate changes in the system. Use version control mechanisms to track and manage changes to components, allowing you to roll back or deploy specific versions as needed. This ensures changes are isolated within specific versions and can be deployed independently.

• Change Impact Analysis: Before making changes, perform a thorough impact analysis to understand the potential effects on other components or areas of the system. This analysis helps identify potential risks and dependencies, allowing you to plan and mitigate any negative impacts. By understanding the dependencies, you can isolate changes appropriately.

This type of loosely coupled approach is important regardless of the complexity of your application. However, there are some differences in the areas of focus you should have depending on the Delivery Model you have chosen for your app.

DIY Delivery Model

In simpler apps, isolating changes makes it easy to know what components and logic have changed, how to validate those changes, deliver them to the users and be confident that work in progress will not be hampered. If you're building an MVP or a DIY project, you may manually orchestrate and agree on who does what. Make sure different people work on different modules or packages. Modern no-code systems allow customizations to be layered on top of each other, so no-code developers modify the behavior and the look with their custom logic and the system merges those customizations into a seamless UI. The team may be structured around different domains and work on different sets of packages not interrupting one another.

CoE or Fusion Team Delivery Models

As your app increases in complexity, you can rely on Composable application versioning to gradually develop and track application changes. Plan ahead of time regarding the development timeline and key milestones and plan future application versions. No-code vendors often implement automatic application versioning and offers integrations with version control systems (VCS) like Git or Subversion (SVN), to keep track of those version artifacts in different development branches. Each significant functionality increment must be developed on a separate development branch. This allows for independent development of the new functionality and unlocks maintenance and patching for the current stable branch. Apply the concept of feature toggling to turn functionality on and off. Feature toggling is a technique that enables the activation or deactivation of specific features or functionalities within an application. It allows developers to control the availability of features independently, separate from the application package or deployment process. With feature toggling, developers can conditionally enable or disable certain features in a live environment without requiring a full deployment or code change. Your no-code vendor may provide feature toggling out-of-the-box to isolate different streams of work and allow maintainers to turn-on features for selected user or group of users. In case the functionality relies on business process workflow automation, use no-code features like business process versioning to create multiple versions of the processes and switch between them when needed. Implement gradual rollout or phased deployment strategies for larger changes. Instead of deploying changes to the entire system at once, consider deploying them incrementally to a subset of users or components. This approach allows for early feedback, validation, and the ability to isolate and address any issues that may arise. Implement monitoring and observability mechanisms to detect and respond to any issues or anomalies introduced by changes. By having visibility into the system's behavior and performance, you can quickly identify and isolate any issues that arise from changes, minimizing their impact on the overall system.

By using these options to implement change isolation practices in your no-code app, you can ensure that modifications and updates can be made more independently and with reduced risk, leading to a more flexible and maintainable application.

Quality Gates and Test Automation Are Two Important and Related Elements of Your Everyday Delivery Strategy.

• Quality gates set up a clear set of preconditions that must be fulfilled for the functionality to be accepted as ready for deployment. This step is focused on safely getting changes into production. We have defined quality gates for each stage of the no-code lifecycle which will help ensure the next stage is not started without the appropriate level of pre-requisites being met from prior stages.

• Test automation is required to apply quality checks that must be run on every change before it is released to the end users. Any manual checks should ideally be eliminated to allow Everyday Delivery. This is one of the main differentiators between low-performing and high-performing organizations that benefit from rapid deployment.

Applied together, quality and testing practices ensure the stability and correctness of the system during and after changes – even when moving at a high-velocity pace. They help identify and isolate issues introduced by changes, allowing for quicker resolution.

Before we dive into tips and practices, a few words on Quality and Testing. In Stage 5 (Prototype to MVP), we discussed some aspects of your Quality/Testing methodology should change a bit with no-code when compared with traditional custom development. Traditional software testing methods anticipate many software defects can be introduced during the low-level coding process and set quality gates and validation steps to identify and remove them. In contrast, while defects will certainly still need to be removed from a no-code app, the abstraction layer of the no-code platform provides guardrails that help prevent you from making lower-level technical coding defects.

With no-code, your focus should be on testing scenarios that validate the end-user features and user journeys to be delivered in the app. Traditional unit testing activities are not typically needed, as they are short program fragments that are written and maintained by the developers that exercise some narrow part of the product’s source code and check the results. In no-code, however, there are few (if any) original ‘units’ of code. Instead, each of the smaller components of the app is usually a prebuilt unit supplied by the no-code platform and assembled into higher-level functional components (e.g., forms, workflows, etc.). This allows teams to put focus on validating business rules and end-to-end user scenarios rather than having to unit test for minute defects accidentally introduced during coding.

So let’s dive into some tips and guidance. Both Quality Gates and Test Automation are important regardless of the complexity of your application. However, there are some differences in the areas of focus you should have depending on the Delivery Model you have chosen for your app.

DIY Delivery Model

Quality Gates As you develop the application, make sure there are quality requirements enforced before any change is delivered to the end user. Define a gatekeeper - a person or a group of people - who decide the changes are ready to go. List criteria that must be met and make those available to your team. Quality gates can be enforced on any area of the No-code Lifecyle, but in smaller projects we suggest starting with the requirements as defined in the Business Use case. Informal pairing of no-code creators with business SMEs or stakeholders may trap errors early. Make two people work together asking questions, defining edge conditions, testing and validating the requirements. Capture these exchanges into checklists that may be reused in user acceptance testing on the first release and in the following releases. Use peer-review process to let other team members review and walk through the changes with the author. Peer review ensures that the best practices and guidelines are met, the logic corresponds to the original intention and is easy to maintain in the future. Then, during Final User Acceptance Testing (Stage 8), make sure the new functionality fulfills its goal and existing features still work as expected. Use checklists created by no-code creators to consistently repeat the same checks each time you deliver feature increments. Apply requirement testing, peer review, acceptance testing with checklists consistently. Assign a role of gatekeeper to supervise this process is repeated every time you want to introduce changes and you'll get increased confidence you're not breaking things in Everyday Delivery. Testing Automation For smaller projects look for simple ways to automate your testing. Adopt well-known tools like Selenium IDE, TestComplete, Ranorex Studio, or try emerging competitors like Katalon or Playwright that challenge the leaders by providing more usability features and tighter browser integrations. There is a vast set of tools for software test automation for practically any domain and expertise level. Using no-code platform capabilities, setup a separate QA and UAT environments and automatically move your application between those environments as the validation step completes. Always have your checklists, test scenarios, and test executions well documented and versioned with the application, so there is no misunderstanding about what steps must be done to verify application quality. Use the record and playback automation tools to easily and simply define a set of acceptance checks to be run on every version released. The benefits of record and playback tests are that they’re easy to start and use for everyone, you don’t need to know how to code, and they reduce the time spent on repetitive tasks. You simply need to perform the manual steps in your application on QA environment and let the tool record your actions and then playback to rerun and repeat them again. You may follow these steps to adopt test automation: Define a set of scenarios to be repeated Document what environment, user role and start data must be created Prepare those prerequisites and record automated scenarios Setup a schedule and conditions for rerunning automated scenarios as part of your delivery routine. Finally, keep in mind that to execute automated testing you may also need to provision more environments or apply cloud computing for the test infrastructure to dynamically scale for automation needs.

CoE or Fusion Team Delivery Models

Quality Gates In a more complex solution you may want to build a more formal and automated process to enforce quality gates across the no-code Lifecycle. Still, use requirements testing and peer reviews to identify bugs at early stages. We recommend using wikis, task trackers, version control systems and automated code review tools to keep track of requirements, configuration, code, and test scenarios that must be executed to deliver a new application version. You may want to involve your no-code architect, security, and compliance personnel in defining and reviewing a set of rigorous checks that major requirements are fulfilled before the release. The CoE will play a key role typically in defining a common set of reusable quality gate templates and practices, and for providing enablement across no-code teams on effective use. Test Automation The CoE will also play a key role typically in test automation, as this may require (as you scale), a larger amount of coordination and enhancement of the test automation and environments. The CoE will also play a lead role for providing enablement across no-code teams on effective use. In Fusion development scenarios, you will be including custom code that may have been written by professional developers. This will require the use of unit tests to be layered selectively into your release processes; have the developers write unit tests for it and run them on each commit. In simpler apps your test scenarios may be focused on specific features or areas of the app. However, as your application increases in complexity, add to the granular tests additional test scenarios to cover end-to-end journeys for common user actions. Write automated UI and acceptance tests that are easy to run on demand. Make sure to fully use the no-code platform’s ability to provision several environments to set up multiple parallel streams of verification quickly. Depending upon the number and complexity of the integrations, you may want to invest time in API testing (using tools like Postman), especially for newly created data exchanges. API or contract tests can be helpful in rigorously validating any integration points of the application, especially to catch API changes that may cause regressions. In simpler apps your automated testing scripts may have been played on-demand at certain spots in the development process; in more complex apps, you should consider running them on a scheduled basis (e.g. daily, weekly), to allow for a broader test of regression across the full application. Most automated testing tools allow for automated comparison against expected results, which will help streamline the analysis of test results when executing larger batches of automation scripts. Frequent execution of automated tests is a best practice in implementing Continuous Integration (CI), which was discussed in Stage 8 (First Release). In CI you operationalize a practice of integrating all changes into a shared repository which helps identify early any possible conflicts and streamlines the release process. Multiple contributors integrate changes several times a day, and each integration is verified by automatically running a set of tests. Use cloud computing environments to scale your execution and run as many automated tests as you need to ensure quality.

Overall, use of quality gates and automated testing in no-code development streamlines the testing process, enhances reliability, and facilitates faster and more efficient development cycles, ultimately leading to higher-quality and more robust applications.

Automated deployment focuses on getting changes into production sustainably and efficiently. We discussed this topic briefly back in the First Release stage (Stage 8), but it’s even more important as part of your on-going Everyday Delivery strategy.

Here are some key areas of focus when implementing deployment automation to support on-going releases in a no-code environment:

• Version Control: Utilize a version control system like Git or Subversion (SVN), to track changes and manage your no-code project. This allows for collaboration, rollback capabilities, and a clear history of modifications.

• Continuous Integration: Integrate your version control system with a continuous integration (CI) tool. This enables automated building, testing, and packaging of your no-code applications whenever changes are committed to the repository.

• Deployment Pipelines: Set up deployment pipelines that define the stages and actions required to deploy your applications. These pipelines can include steps such as building, testing, and deploying your no-code projects to different environments (e.g., development, staging, production).

• Environment Configuration: Maintain separate environments (e.g., development, staging, production), with appropriate configurations. This ensures that changes are thoroughly tested in non-production environments before being deployed to production.

• Rollback and Monitoring: Have mechanisms in place to roll back deployments in case of issues or failures. Additionally, implement monitoring and logging solutions to track the performance and behavior of your no-code applications in real-time.

As before, we will discuss some differences in the areas of focus you should have depending on the Delivery Model you have chosen for your app.

DIY Delivery Model

The complexity of managing multiple environments and application availability is handled for a no-code creator by the no-code platform. The platform will ensure the application is deployed on a compatible platform version, manage dependent components installation, or even provide an abstract called delivery package to wrap an application and all its dependencies into a single deliverable. Use automated application setup, automatic transfer between environments, and manage available environments and their resources all within the application lifecycle management portal. These automated operations enable critical deployment tasks to be done in a matter of minutes and repeated as many times as required. Even with simple apps, it is important to document and operationalize a defined release management process to control the deployment of new versions. This can involve release branches, code reviews, and what approvals are needed before promoting changes to production. Even if it is not fully automated, you should be sure to have documentation that describes the deployment process, environment configurations, and any specific considerations for your no-code applications. This helps ensure consistency and enables easy onboarding for new team members.

CoE or Fusion Team Delivery Models

The CoE should play a key role typically in defining a common set of deployment automation practices, and for providing enablement across no-code teams on effective use. This can require specialized expertise to initially setup and support, but can be a very powerful and leveraged investment across no-code teams. For more complicated no-code apps, introduce automated deployment pipelines connected to your version control systems to trigger builds, environment provisioning, and application deployment on every change made to an application. In Fusion development scenarios, you will be including custom code that may have been written by professional developers. This may require the integration of deployment automation for these custom components to be integrated into your deployment pipelines. You can use standalone automation servers like Jenkins or TeamCity to orchestrate automated deployments, or use continuous integration/continuous delivery (CI/CD) workflows provided by Github, Gitlab, or Azure DevOps. Each of the options provides the ability to run automated actions triggered by events like the appearance of the version in repository, passed test suite, security sign-off and quality gate clearance as frequently as you wish. Use powerful application lifecycle management capabilities available in the no-code platforms. ALM features allow fast application deployments and rollback and allow deliveries to be initiated from the third party continuous delivery pipelines. The mature no-code platform provides a set of monitoring and troubleshooting tools that enable constant environment health checks and allow automatic rollback to return to the previous stable state. Continuously evaluate and improve your automated deployment process. Analyze metrics, collect feedback, and iterate on your CD pipeline to optimize efficiency, reduce risks, and enhance the overall development workflow.

By following these best practices, you can establish a robust automated deployment process for your no-code applications. This enables faster and more reliable deployment cycles, increased collaboration, and improved software quality.