Application Development Process

This section describes the application development process and functions of how to program, test, and publish tasks using the Agile.Now DevOps process. This process has been tested in dozens of OutSystems factories and more than 500 applications have been created through the process. This model supports best practices in agile development, and has the special features required by low code on the OutSystems software platform. 

Fig: Applications that Agile.Now DevOps connects together 

Development environment and test environment

The DevOps process for the development environment and test environment is described below, and the following sections describe the requirements, goals, and functionality of operations to automate the process. 

Fig: DevOps process for the development environment

Ready for development 

All software issues will switch to "ready-to-develop" mode once the business and project team have made the necessary specifications to implement the software component from a business and application development perspective. At this stage, the responsibility of the issue is transferred entirely to the application development team, and the result is assessed in the testing phase. Once the issue has entered the development phase, the issue’s business framework must not be changed in the context of agile development, and the release will be carried out in accordance with the approved specification. 

The issue must be ready with at least the following parameters when it is transferred to “ready to develop”:

• A description of what is being built and why. 
• The criteria for the approval of the issues from a business point of view; what are the behavior of functionality and the necessary changes (behavior & transition). 
• A description of the technical implementation in general. For example, what are the new modules, which modules to change, what is the database structure and similar other information. 
• Adequate modules (Jira components) to group issues for tracking and classification so that the DevOps process can track these issues from start to completion thereby ensuring a seamless process. The modules are subsections of a project. They are used to group issues within a project into smaller parts. For example, teams may use components to group issues that describe work on specific data objects, services, plug-ins, or APIs within their project. You can set a default assignee for a module/component. 
• Each issue must have a clear and concise definition of "Done". This should describe different types of “ready/done” definitions; UX/UI, interface, custom components, database, backend, integrations, manual/automatic testing. See Appendix 1 for more information.

Status changes: 

The issue can return to their state due to either code checking deficiencies or errors detected during automatic or manual testing (DEV, TES, UAT). If the issues return to the development status, Agile.Now will track it and logs it. This enables quality assurance and at the same time the development team receives valuable information about the process, which means that the smoothness of development work can be improved in the future. Logs are also written for a status change if the issue is manually or automatically moved in the project management system (e.g., Jira). 

Fig: Dashboard

Development 

When an application developer starts developing applications, the issue is manually transferred from the development backlog to development mode, either from the DevOps interface or from the project management application.  

Application development process: 

• The developer first ensures that all necessary components (modules) are assigned to the issue that are to be implemented, modified, or resolved in the development work. If modules are missing from an issue, they can be attached to the issue with the help of a project management application. 
• For new application modules, it must be added to OutSystems inside an existing application, or if a new application is created, it must be created in OutSystems and connected to the right team in Lifetime software. OutSystems Help - here 
• When all modules are connected to an issue, all module-related test programs are imported automatically. The DevOps interface presents all tests and UI tests for application development units to the developer in a simple view. 
• The developer makes changes and additions to the applications using the OutSystems software. The user can also open the OutSystems development or test module directly from the DevOps user interface. 
• The developer creates the necessary unit & integration tests using the OutSystems BDD testing software according to the application modules that are developed in either reactive or web. 
• After the implementation is completed, you can start the tests from DevOps, and the tests will be run using automatic testing software and the results will be imported into the user interface. The information about the tests would cover the last time it was run and status of the test, among other things. 
• When the tests work and the program works as expected and all the acceptance criteria have been tested and found to work, the issue can be transferred to "code review"

Fig: Dashboard

Ready for code review 

After the developer has made software changes and integration/unit tests and verified the functionality of the use case, the issue will then move to quality assurance to ensure best practices. These actions prevent application liabilities from arising. It is recommended that workflow in project management software automatically transmits the issue to the right person, ensuring an automated DevOps operating model without manual work. This transfer is easy to make, e.g., in the case of Jira software with workflow. The issue is waiting for a technical lead or a senior application developer to perform the necessary checks and ensure the quality of the app. 

Fig: Dashboard

In code review 

Code review is performed by a senior developer or tech lead and must include all best practice reviews. In this way, we will ensure the quality of the software also in the future. 

It's a good idea to spend enough time on code review if you have a lot of junior developers in the team. This provides a good opportunity to educate junior developers about OutSystems best practices during this process. 

We all know for sure that with OutSystems software, making code is fast and adds great value to the business, but at the same speed can also make spaghetti code. It is important that OutSystems best practices are implemented so that the code does not cause technical debt for the future. 

In view of these issues, it is very important that either the technical lead or a senior developer review the changes to the application to ensure: 

• Approval criteria is met for new functions 
• OutSystems best practices are incorporated 
• Database structures and their best practices (e.g., relationships, indexes, team responsibilities) are followed 
• Best practices for JavaScript and CSS on OutSystems are considered 
• Reusable components and their use, as well as team responsibilities are delegated 
• Documentation is up to date 
• No errors in coding standards, no warnings, no test code on OutSystems modules 
• Scope of unit testing and their coverage

The link below describes the best practices of OutSystems software that are worth following, giving us information on cost savings in the future as well in this link 

Status changes: 

• If all the reviews are correct, the issue is manually accepted for testing and the status moves to wait for manual or automatic release. 
• If any reviews associated with the issue fails, the issue is manually returned to "ready for development" status, and at the same time the results of the incorrect test are automatically logged in the project management software.

Fig: Dashboard

DEV deployment queue

Once the code review has been completed and all the shortcomings of architecture and best practices have been corrected, the issue will then move to wait for manual or automatic release from the development environment to the test environment. 

If automatic testing is configured in the environment before release, Agile.Now DevOps automatically performs all test cases in the development environment associated with the new issues(stories) that are being deployed.  

• If tests related to new issue are correct, let's move on to the publishing process.  
• If any test related to the issue fails, the issue is returned to the "ready for development" status, and at the same time the results of the incorrect test are recorded in the project management software.

If an automatic release is configured in your environment, Agile.Now DevOps automatically publishes all applications that are associated with the issue (through components). If the configuration is inactive, the publishing process can be started from the DevOps interface. 

Test queue 

After the code release is completed successfully, the issue will then move to manual testing. 

The workflow part of the project management software automatically transmits the issue to the right person, ensuring an automated DevOps operating model without manual work. This transfer is easy to make, e.g., in the case of Jira software it’s possible to set rules that would automatically transfer the ownership of the issue to a person when the status of the issue changes. 

If automatic testing is specified in the environment, Agile.Now DevOps automatically performs all test cases in the test environment associated with the process. 

• If all the tests are correct, the process will wait for user intervention. 
• If a test related to the issue fails, the issue is returned to "ready for development" status, and at the same time the results of the invalid test are logged in the project management software.

Test 

Manual testing of the code is carried out by a tech lead or a separate tester(s), and the test focus on new functionalities. During this time, it is a good idea to record test cases with the Ghost Inspector web browser extension so that tests can be run again during the upcoming releases. 

It's a good idea to spend enough time testing if you have a lot of junior developers/testers on the team. This provides a good opportunity to educate juniors during this process. 

It is very important that either the tech lead or a separate tester review the changes to the application to ensure: 

• The new functions meet the acceptance criteria (manual and automation) 
• All happy paths (successful implementation) are covered 
• All unhappy paths (system restore error) are covered 
• Research scenarios (think about how a user could break functionality) are covered 
• Test cases confirms the business scenarios

Status changes: 

• If all the tests are correct, the issue is manually accepted for user acceptance testing and the status moves to wait for manual or automatic release. 
• If any test associated with the issue fails, the issue is manually returned to "ready for development" status, and at the same time the results of the incorrect test are automatically logged in the project management software.

UAT deployment queue 

After manual testing has been completed and all deficiencies have been corrected, the issue will then move to wait for manual or automatic release from the test environment to the staging or production environment. 

If automatic testing is specified in the environment before release, Agile.Now DevOps automatically performs all test cases in the test environment associated with the method. 

• If all the tests are correct, let's move on to the publishing process.  
• If a test related to the issue fails, the issue is returned to "ready for development" status, and at the same time the results of the invalid test are logged in the project management software. 

If an automatic release is configured in your environment, Agile.Now DevOps automatically publishes all applications that are associated with the issue. If the configuration is inactive, the publishing process can be started from the DevOps interface. 

User Acceptance testing and production environment 

The DevOps process for user acceptance testing and production environment is described below, and the following sections describe the requirements, goals, and functions of operations to automate the process. 

Fig: DevOps process for user acceptance testing and production environment

UAT queue 

After the code release is completed successfully, the issue will next move to wait for manual testing in the user acceptance testing environment. 

It is recommended that workflow in project management software automatically transmits the issue to the right person, ensuring an automated DevOps operating model without manual work. This transfer is easy to make. 

If user acceptance testing is specified in the environment after publication, Agile.Now DevOps automatically performs all test cases of approval testing in the environment associated with the testing. 

• If all the tests are correct, the process will wait for user intervention.  
• If a test related to the issue fails, the issue is returned to "ready for development" status, and at the same time the results of the invalid test are logged in the project management software. 

UAT 

Manual approval of a user's story is performed by the owner of the product or a separate business representative, and the acceptance focuses only on new functions. It is very important that either the owner of the product or a separate business representative review and approves the changes in the application to ensure that: 

• The new functions meet the acceptance criteria. 
• New operations meet business needs  

Status change: 

• If the functions meet the acceptance criteria, the issue is approved for manual publishing in the production environment. 
• If any of the acceptance criteria related to the issue do not match the functionality, the status is manually returned to the " ready for development " status, and at the same time the rejection of the flag is automatically logged in the project management software. 
• Attention! The idea behind user acceptance testing is to accept the defined criteria, and it is natural for the approver to find suggestions for improvement and new functions, but they do not stand in the way of production release, but to record a new issue that will be introduced after prioritization in the future.

Prod deployment queue 

After the user acceptance testing is complete, the issue will then move to wait for the manual release from the user acceptance testing environment to the production environment. 

Publishing to production is always done manually from the acceptance testing environment by the DevOps or OutSystems lifetime software. DevOps does not allow automatic publishing, but each production release must be made manually by starting the publishing process.

Attention! The production environment does not include Agile.Now DevOps software, but the release is fully managed by the release of the OutSystems lifetime software. 

Closed 

The new functionalities have been transferred to production and then the process is restarted from the start point, allowing us to bring back a large number of new functions that support the digitalization of your business.