Agile software deployment with OutSystems
Usually I see the same questions and doubts when I work in a new project: How OutSystems(OS) handles the source code version and how it is deployed? How I handle developed code to not be broken into test environment? How can I organize the software developer work to avoid source version control conflict? How many environments I need to create and deliver a system?
OS can be 7x faster to create any system but if you don’t understand the OS context and don’t establish your process, you will pay dearly for your mistakes. I will try to keep this article generic enough to be used in all agile environment and towards to all low code adoption(if you have doubts about low code market, check my article here) and who knows if I can help you to save your time and money?
Source code control version
OS integrates the source code control in the Service Studio (SS). Only a version without error is published into the server through the 1 click publish (1CP) button. Once SS detects conflict in the deployment of source code a screen is challenged to the developer to adjust properly the problem detected. The challenge message appears only when SS cannot detect automatic merge and once code is deployed number associated to a flag of published indicates the reference of source code that will be used as reference in the entire lifecycle. If you are curious about use of OS in a team collaboration, head here for more information.
Environments needed to create a system with quality
My initial suggestion to create an infrastructure to deliver a software is to use four (4) environments:
- Development (DEV): where developers create the system
- Testing or QA: used by testers to check the quality of developers work
- Staging or User Acceptance Test (UAT): where the software owner approves the software received and
- Production (PRD): where the system is delivered to the final user
The advantage about choosing 4 environments is that it is possible to copy data from production to UAT. Of course that there are restrictions once a bank, for instance, will not provide confidencial data to store in UAT environment. Real data enables a fine tuned environment to testers to do a better job once it avoids a lot of possible surprises that could appear in production. UAT is a good opportunity too to isolate customer tests and avoid some undesirable change in the database made for some technical tester. Besides all the cited benefits, there is another important factor to take into account when you have to decide about the quantity of environments: OS usually provides 3 environments (DEV, QA and PRD) and charges the customer for the fourth environment. 3 environments can be a save approach.
Once environments are defined you will need a process and tools to keep up with development. Usually a process, like in the picture, establishs a flow from development, QA, UAT and Production. Each process will work to delivery a corporate application that can be mapped to Admin, Back Office, Portal and Mobile functions developed using OutSystems V11 that will be deployed in the dev environment. The tools that can manage this process will be available after the best practices and assumptions topic presented below.
Best practices and assumptions
I faced some problems during my work on some projects and here I will present and explain how some changes or different approach on the way you work can bring an expressive benefit to the project.
- Planning the deployment in advance: the thinking on deployment usually is done in advance. The architect should define and combine modules according component responsibilities and granularity in the architecture (to understand a little more about types of architecture, read my another article here). A good module/application organisation will decrease merge and conflicts on them during 1CP. A standardization of modules name will help to filter the source applications when creating the deployment plan. Clear ownership of modules and applications will remove doubts about who needs to authorise the push to production. Conflicts usually apear during deployment because application teams are working in a different pace or prioritization to deliver a sprint.
- Collaboration: during the estimation phase don’t assign members to the tickets/user stories. Developers work at different pace and once they get a ticket available in the “bucket” you will have a set of developers working to finish all work.
- Definition of done (dod): dod is important but keep all team together during the estimation phase. Developers and testers will understand the requirements from the same perspective, so they will have the same goal when the test phase arrives. Be very clear on what is expected to deliver. This will save a lot of time in the future.
- Broken code: avoid hot fixes (fix done in a specific environment without following the entire process). In development environment, assure that developers keep the code stable, freeze development before and during pushing to QA. They can return to the previous stable version (do you remember that published flag?) and restore their changes after pushing. This will help you to deliver a stable version.
- URL of issue: avoid beautiful print-screens. Provide the url from the page where the issue appeared. The developer will use it to go straight to the page to handle the problem.
- Strategy to push: depending on the way the system was developed would be better use an approach of full deployment. Usually you only move the modules that were changed by developers. If you don’t know very well the system that will be pushed, it is faster move all modules than investigate all dependencies.
- Avoid wastes: tickets failed should be priority for developers and they must work on them as soon as they finish their current tickets.
Tools to keep up with the development
Usually development teams use a Kanban board to follow up the stage of development. Jira is the most common used tool and I will compare it with Plus. Jira maps and creates workflow for statuses. Plus creates “environments” and maps their standard statuses. You will not see in my Jira proposed workflow the common define column used to store user stories that need a better requirement detail. From my point of view, only completed and well structured user stories should be into sprint. If you add a not very well accurate user story, you will increase the risk of failure in your current sprint.
The Jira software development lifecycle proposed is: put all “tickets” (usually Jira uses the term issue to any asset created into it) into “To Do” column that are part of sprint scope and move to “Dev in Progress” that one initiated. Once ticket is completed, moves it to “Dev Completed”. Once you check the tester availability and enough completed ticket quantity, make a push to QA and move the completed tickets to “Ready for QA”. Testers will move the tickets to “QA in Progress” as soon as they work on them. Failed tickets will return to the “Failed” column and will be fixed by developers, otherwise they will follow to the “QA Passed” column. The same process follows from UAT to Production. Blocked tickets usually are forwarded to “To Do” column through the workflow.
Plus works similar to Jira when uses its kanban card. The difference is that you can see the tickets evolution based on its color status associated in the summary view. The detailed view show tickets organised by columns of status. The “Planning” column is used to prioritize the tickets that will be finished first. Once you select the ticket and assign it to yourself it is possible to track all tasks developed of specific kanban card. When the task is finished you only have to move the card to the next environment column showing automatically the next available pre-defined task.
Conclusions
There is more than one way to answer the questions raised in the beginning of this article. I am sharing advices that helped me to get good results in my projects. Possibly people will have different opinions of mine, suggesting another approach. You can take only what is most important for you. My main goal is to contribute to improve general productivity, avoid common mistakes during software development lifecycle and save some time and money. Enjoy! I wish you a nice week :)