Subversion Control

Subversion Control

We would like a solution to our subversion control using outsystems.

Currently, we have several developers in different locations working on an application based in silverlight.  Mainly, we use outsystems to create web services that we use in the applications we develop.  We decided to have one OML file with multiple web services, and call those services as needed.  However, we are having trouble deciding how best to control the source OML file and assocated Extension file.

This is our subversion control process in theory:
  1. Have a central OML file.
  2. A developer uses Visual VSN to get the latest OML file.
  3. The developer copies the file to his local machine, so as not to make changes directly to the central OML file.
  4. The developer makes changes.
  5. The developer merges his local OML file with the central OML file.
  6. The developer saves the updated central OML file.
  7. The developer lets the next developer know they can repeat the process for the next set of changes.
We would like to use a subversion control such as VisualSVN or the like to manage the suversion control of the OML and Extension files, but are unsure how to do this, so we came up with the process above.

Any ideas?
Hi Adam, 

i'm trying to figure it out why did you added one more level of version control for extensions and espaces.

Are you using different environments (development, quality and production) in your factory?

I've been doing complex projects, with multiple developers and also based on different locations and didn't had the need to have a subversion control tool. Using debug, merge & deploy has been the solution.

When you say "We decided to have one OML file with multiple web services", by multiple you mean 3? 10? 100? Are all webservices to integrate the same app or have different sources? Only having answers to these questions i can give you help to decide if that was a good architecture solution or not.

If you want to stick with SVN, I would recommend TortoiseSVN for oml's and xifs...

But I lack to see the advantage, becuase you cannot really do a diff on 2 versions.

I do want some sort of dedicated version-control for OUTsystems though, because I work for many clients, and all those OML's should be archived somewhere, and tbh, our own development-server is for developing, not storage :)
Hi Joost, 

in your scenario i can see why you need a different tool to store oml and xif, but as i see its more like a code repository to store code from releases on a customer project, but during the development you use service center to control de development versions.

Adam, i really would like to understand more of you needs to see how can Service Center be improved in source control.

Hey Ricardo,

Let me re-explain our situation here.  Maybe we just aren't undersanding outsystems very well.  We are new to the process and the software.

We started using outsystems about a month ago.  We are creating an application in silverlight.   We use the silverlight classes mainly for display.  Most of the business logic is developed in outsystems.  Using outsystems, we have four web services, with 20 or so methods per web service.  From the silverlight code behind files, we can access the web services.

Now, my question is how do we best manage our outsystems exension and OML file subversion control.

What is the best way to do this in outsystems?  We have multiple developers in several locations, and need to track our changes to the central OML file that has the web services we use.

Hi Adam,

I would like to highlight some details about the way versioning is managed in the OutSystems platform:
  • Continuous Integration - OutSystems teams work using a "continuous integration" model - each developer works in his private testing area and continously merges his work (using our visual merge tool) in the common trunck. In this video you can see how continuous integration works.  Read the Overview of eSpace Life Cycle article to better understand this process.
  • All publications are stored in Service Center - All versions of your applications, components, and adapters are stored in Service Center, from the time they were first created - transparently whenever someone deploys an application. With Service Center you can navigate through versions, see when and who published them, download or roll back to a previous version with a single click.
  • Support for multi-eSpace and multi-extension versioning - complex applications are composed of several eSpaces and extensions. The OutSystems platform includes the concept of Solution - a solution is basically a group of eSpace and extension. Solutions can be versioned and published or rolled-back with 1 click.

One other important detail about the OutSystems platform is that you can create modular architectures - if your solution is complex, you can structure it in several different eSpaces so that you can isolate complexity and reduce the number of dependencies between modelues. With this in mind, I would like to ask you why are you implementing all you web service actions in the same eSpace - isn't it an option to devide it in several eSpaces? By doing this, you will have a much finer control over what is changing in your web services (because the developers will published only the portion of the functionality that they change, instead of publishing everything). This will also avoid the need for "merge" operations when developers change different parts of the application.

Kind Regards,

Daniel Lourenço
Thanks Daniel,

We still have a problem:  What do you do when a new developer comes on board?  What OML file should you give him? 

You see, we have muliple developers and we are not all on the same network.  Ideally we would like to have a production Solution, a Development Solution, and then a Solution/eSpace for each developer.  Developers would merge their own local OML and extension files with the Development solution, and then we would merge that with the production solution.

In other words, how do you manage the subversion of the OML file with multiple distributed developers?  And what should we give the new developer?  Does the merge process generate an OML file?
Hello Daniel,

So we decided for the time being to go with one eSpace for all of our web services.  We could change that in the future, but it is simpler for us because we use one set of entities for all the services.

My question is, how do you manage a development eSpace when all of the developers are not on the same network? 
(eg we have developers in different countries, and far away from eachother)  

We would like a simple way to keep track of changes among the developers in a development environment, test it, and then take it live to a production eSpace solution.

Hi Adam,

Usually even though the developers are not on the same network/countries they share the same server.
In my personal opinion your aproach is a bit "overkill", even though it represents the traditional code/aplication development cycle.

Using the same server you don't have to worrie about "What OML file should you give him".
A developer opens Service Studio, connects to server and can use the "Download" button to get the most recent (or a specific version) of the eSpace from the server.

As for the decision to use only one eSpace for everything, you should reconsider about using several eSpaces and use references to connect the pieces.
Using references
you can still keep all the entities and related logic in specific eSpace(s) and then reuse it on the others.
João Rosado
It doesn't seem like outsystems can manage what we want to do.  We'll just have to manage the subversion conrol between our dedicated eSpaces ourselves.  Thanks for the comments though.  We will look into references for our framework too.
Hi Adam,

Well, if that's the case, why not suggest it in our Wisdom of the Crowds? That way others can vote in your idea, and our Product Management team can also become aware of such a need, and consider it in the future.

One thing you could also consider is developing in a cloud server, since then all developers could share the same server without worrying about where to host it.

Regards, and let us know if you manage to implement a good process to work in this particular scenario.

Paulo Tavares