Mark commit to the repository

Dear Outsystems. We work with Jira tickets in Agile teams. Please tell us how the developer can mark his commit to the Outsystems repository with the application number in JIRA? Why when you click the Publish button, the developer is not able to put an additional comment on your commit. Why is it so uncomfortable made the repository in Outsystems?

Hi Sergey,

Doing what you want is not possible. There is an idea for it.gibe your vote if you would like to have this functionality.

For now the only thing you can do is when you are tagging a version on lifetime you can add a description with all the Jira tickets that were finished during that version.

Regards,

Marcelo

Honestly, I do not understand why it is difficult to finalize the platform for such a high-tech company? Add a string field "description" for the commit.  When you click on publish, prompt the user to fill it out.  Write this field to the repository along with the version number and timestamp and display it in the repository. I'm beginning to doubt the professionalism of the Outsystems platform developers.

Is the platform moving in the right direction? Controlling the developers on it is some kind of hell.

Why this can be done in all version control systems such as GIT, VS, Mercurial, SVN and others. And why is such an elementary thing missing from the Outsystems platform? I have 60 developers who are almost impossible to control. Why is everything so horrible with the Outsystems platform?

Hi Sergey,

Sry to hear you having a hard time with Outsystems. But you can't compare the one click publish of Outsystems with the commits on those systems because is not the same thing. One click publish is the build of the project and you will have multiple of those for each Jira while doing and testing the functionality. After you finish that you will do the commit to the repository and on Outsystems you can compare that with tagging a version.

Regards,

Marcelo

Thanks Marcelo for endorse my ideia. 

Regards

Dear Outsystems, tell me how you can control developers manually with the help of your wonderful development tools? JAVA EE 9.1


When even a commit developer can not mark the application in JIRA.

It's true that the Outsystems merge could stand to be more robust - but it seems to me that the goal of the system has always been to make it an easier and smoother process than any of the source control systems that you mentioned: you don't need hours to explain to each developer how your source control operates, and there are very few cases of "nightmare merges" that are common to those systems.

In Outsystems projects those issues tend to be dealt with actual project management and areas of responsibility for each team, minimizing conflicts and issues when it's time to merge work, rather than a free-for-all.

Sergey Palagin wrote:

Why this can be done in all version control systems such as GIT, VS, Mercurial, SVN and others. And why is such an elementary thing missing from the Outsystems platform? I have 60 developers who are almost impossible to control. Why is everything so horrible with the Outsystems platform?

I'm not sure the goal of any developer is to be "controlled", so at least it makes sense that you're finding it impossible.


Afonso Carvalho wrote:

It's true that the Outsystems merge could stand to be more robust - but it seems to me that the goal of the system has always been to make it an easier and smoother process than any of the source control systems that you mentioned: you don't need hours to explain to each developer how your source control operates, and there are very few cases of "nightmare merges" that are common to those systems.

In Outsystems projects those issues tend to be dealt with actual project management and areas of responsibility for each team, minimizing conflicts and issues when it's time to merge work, rather than a free-for-all.

Sergey Palagin wrote:

Why this can be done in all version control systems such as GIT, VS, Mercurial, SVN and others. And why is such an elementary thing missing from the Outsystems platform? I have 60 developers who are almost impossible to control. Why is everything so horrible with the Outsystems platform?

I'm not sure the goal of any developer is to be "controlled", so at least it makes sense that you're finding it impossible.


The problem is that you probably have not worked in large projects, when teams have a lot of outsourced developers who do not care how to write code. Or you do not understand all the problems of automation of a huge enterprise. When simultaneously working on different features in hundreds of Jira tickets, in which the release dates vary. Immediately emerge all the problems of such a one-sided merge. And the problem adds another and the inability to label the commits in the repository of applications in the Jira.


Teams still intersect, like it or not. There can't be multiple entities, such as "person, customer". And when these entities begin to use 10 or more teams, here begins to emerge unmanageable developers.

It seems to me that you have a set of issues in your hand and you're working under the assumption that they can be solved by Outsystems having a more complex merge system.

If you have people working on your team who don't care about the code they write, then you don't have a tool problem. You have a people problem. It's going to cost you in the long run whether you're using Outsystems or you're writing Java using Eclipse and SVN.

I couldn't agree more with Afonso's comment. Tools help you be more efficient, but it doesn't guarantee the quality of your work.

We already agreed that OutSystems lacks the notion of "commit message". You have been shown an idea that you can vote to influence the roadmap of the product.

However, most of us have been and still are involved in large enterprise projects, spanning multiple teams, doing multiple releases. We manage the absense of a "commit message" or "log history" by having a tech lead and/or architect involved in the project, and by having constant communication within the team.


If you need to link JIRA to OutSystems versioning, you can always use the version of the module the developer is publishing. You can get that information in Service Center, or by using "Open other version" in Service Studio. It's a manual process, but you could even automate that using the OutSystems metamodel (which exposes all versions of all modules, and who published the version, and at what date/time). But I'm not sure if that would help you manage the team much better - you could get a good approximation just by asking during a stand-up meeting in the morning: "was feature A committed in OutSystems? if so, please update the JIRA card with who did, at what date/time, and a summary of what was done".

leonardo.fernandes wrote:

I couldn't agree more with Afonso's comment. Tools help you be more efficient, but it doesn't guarantee the quality of your work.

We already agreed that OutSystems lacks the notion of "commit message". You have been shown an idea that you can vote to influence the roadmap of the product.

However, most of us have been and still are involved in large enterprise projects, spanning multiple teams, doing multiple releases. We manage the absense of a "commit message" or "log history" by having a tech lead and/or architect involved in the project, and by having constant communication within the team.


If you need to link JIRA to OutSystems versioning, you can always use the version of the module the developer is publishing. You can get that information in Service Center, or by using "Open other version" in Service Studio. It's a manual process, but you could even automate that using the OutSystems metamodel (which exposes all versions of all modules, and who published the version, and at what date/time). But I'm not sure if that would help you manage the team much better - you could get a good approximation just by asking during a stand-up meeting in the morning: "was feature A committed in OutSystems? if so, please update the JIRA card with who did, at what date/time, and a summary of what was done".

Do you seriously think that one architect without automation, manually, asking specific developers on standups what they have done, will be able to control manually the development of 30 teams and more than 100 developers? Really?


Then such an architect must be God. Developers of Outsystems platform, listen finally to your customers who are suffering. In large corporate projects the scheme with manual control of developments by the architect will not work. Need a more automated means of monitoring development. 1. We need a static code analysis tool like SonarQube. Which would conduct a comprehensive analysis of the code generated by the developers and forbid publishing according to certain rules. 2. Communication needs of commits in the repository Outsystems and tickets in JIRA (to understand which problem solves a particular commit in the repository). 3. Need a normal merge code, as in other systems. To be able to automatically release only those Jira applications that are already ready for release in the stage. Approach deploym stage in the latest versions of the module are very hard takes place in enterprise

Sergey. If you have 100 developers, each one of them can update their own JIRA card. It doesn't take much maturity for a developer to manage their own JIRA cards, updating the status, adding comments, and relating cards with dependencies. That is not the work of an architect. And it's not the work of God either.

The architect would help designing reusable components, managing technical interdependencies between teams, and updating the architecture - such as entity diagrams and interfaces between subsystems. The architect could also perform code reviews himself, or promote teams to review each others' code.


The impression I have from your posts is that your developers are not doing their jobs. Of course you have an unmanageable situation, if one single person has to update JIRA cards for 100 developers, without having any context on what they have been doing with the code. Do you really blame OutSystems for this problem?


Finally, this is not the best place to ask for new features. I don't think there's any product manager reading your posts. The place for that is the Ideas board.

Why do you have one architect trying to gather feedback from 100 developers? Why is the architect not interacting with the lead of every team? Why do you have one architect for a factory with almost 2500 Entities?

Outsystems could implement your 3 points and I don't think any of them would solve your problems. You've already decided that this is a tool problem, but you still haven't told us how all of this would be solved with more automation and more software tools.

You don't solve people with software.

I have the impression that you really did not work in large projects with more than 3 teams and more than 3 developers and do not understand all the problems of a large enterprise. Tell me, please, how to solve the next case arising in the enterprise by hundreds. 1. There is a ticket in Jira 00001 and ticket in JIRA 00002. Both have to implement different features in espace for example "Insurance". Release date in production Jira 00001 - 01/08/2019. Release date in Jira 00002 - 15/08/2019. Two developers of the same team develop code in parallel. The first developer has capablity code on the Jira ticket 00001. The second developer capablity code 00002 Jira ticket. Then first a developer has fixed the code in the Jira ticket 00001. Then the second fixed the code on the ticket Jira 00002. Have four publish to the repository by two features. And now comes 01/08/2019. Jira 00001 - you need to deploy in production, and Jira 00002 is not ready yet and needs to be improved. How in this case to deploy the wonderful tools Outsystems code in the production feature Jira 00001 and not tightening Jira 00001

This is the simplest case. And now what's going on in the big enterprise. Espace Insurance is linked by dependencies with other espaces. And the Jira 00001 requires further refinement in three espaces, and the Jira 00002 in four, two of which overlap with the Jira 00001. And then 27/07/2019 the first developer got sick and the second developer was asked to modify both Jira 00001 and Jira 00002. Comes 01/08/2019 and need to deploy in production Jira 00001. How to release Jira 00001 without any modifications to Jira 00002?

And now I'll tell you what happens to the developers in this case. They are long and boring trying to figure out what you still need to deploy, what are the espace and how to merge them correctly. In the end, the pieces JIRA 00002 fly in production with JIRA0001 because nobody understands this terrible dependency.

Sergey Palagin wrote:

And now I'll tell you what happens to the developers in this case. They are long and boring trying to figure out what you still need to deploy, what are the espace and how to merge them correctly. In the end, the pieces JIRA 00002 fly in production with JIRA0001 because nobody understands this terrible dependency.

Hi sergey,

I'd like to answer from my own experience as a developer in a large company with 100+ devs distributed in two countries and many agile groups all using the platform at once. At first, we had the same impression as you, we kind of feel the need of having our "standard"  project management tools back, mainly the lack of branching and a Git like repository. So we had to reinvent ourselves.

With the support of Outsystems team we managed to change the rules of what we were doing. We empowered our architects and tech leads to have more control over the platform, developed apps to monitor every change in every module so we can relate it to a specific Jira ticket, we enhanced our available prod environments so the deploys won't affect other applications, we also had found a balance of application dependency with reusability of components. 

Every day we face new challenges and roadblocks but, I think the use of a low code platform like Outsystems requires a change the mindset from traditional development, not only for IT teams, but company wide. And, if you are simple not willing to do this change, maybe the tool is not right for you. 

I won't be selling Outsystems to every software factory out there. But some companies will find it more suitable for them than others.



Sergey Palagin wrote:

This is the simplest case. And now what's going on in the big enterprise. Espace Insurance is linked by dependencies with other espaces. And the Jira 00001 requires further refinement in three espaces, and the Jira 00002 in four, two of which overlap with the Jira 00001. And then 27/07/2019 the first developer got sick and the second developer was asked to modify both Jira 00001 and Jira 00002. Comes 01/08/2019 and need to deploy in production Jira 00001. How to release Jira 00001 without any modifications to Jira 00002?

This isn't specific to a large factory. You'll run into this in a one man project. If you're working with large enough features that they'll take longer to implement than everything else, you either split them apart into smaller working units, or you make sure the code is disabled or being built parallel to the system while it's being worked on, ensuring it doesn't break anything while its being built.

Why was unprotected code written for the second ticket when both developers knew there was going to be a push to production halfway through, and making sure no unwanted changes leaked to production was paramount?

Sergey, thanks for writing a specific scenario. This has nothing to do with JIRA integration. It has to do with feature isolation, or branching as it's usually implemented in Version Control Systems. And, yes, you have a point that there's no such thing in OutSystems (at least not supported by tooling). Here's a community idea to promote the feature request: https://www.outsystems.com/ideas/160/branching


It is, however, possible to manage concurrent feature development with feature flags (see https://www.outsystems.com/blog/posts/fun-with-feature-flags-live-mobile-apps/). Again, this would need to be orchestrated at a product lifecycle level, so both features in Jira 00001 and Jira 00002 would have a known release date and an estimated effort, and if there was a risk of a feature not being complete on a given release date, it would need to be hidden behind a feature flag.

Another alternative would be to isolate each feature in its own application, in a way that each could be released independently at a particular date. This might be possible depending on the specifics of the features and of the release scope.