Agile software deployment with OutSystems

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

Processes and environments to create and deploy a system

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.

Plus and Jira proposed workflows and statuses

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 :)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Luciano Schiavo

Luciano Schiavo

PMP Certified | Togaf 9 and Business Architecture Certified| LSS Black Belt | Solutions Architect |Productivity Improvement Researcher