We have deployed a lot of new codeless logic to this timer. We are 100% sure we deployed it around 15:00 UTC yesterday.
It is all gone and the version is the older one. There is nothing in Changelog.
Is there a possibility to recuperate our code from your backup files?
Hi,
No, such problems have not been reported yet. Is there any chance that two people work in the application or one, but from different computers? in this case, there could be a situation when a deployment was made on the first computer, and the page was not updated on the other computer and the deployment was also subsequently made, which would lead to the logic fraying. This is also indicated by an empty changelog in your application.
Regards,
Stanislaw
@Stanislaw Grin Yes we do have 2 people working at the same time, but not on the same logic. We are assuming that a deploy is limited to the method being deployed. For example if I am deploying method A while my colleague is deploying method B, this does not affect one another. Is our assumption correct? Then this is not the root cause. The issue I have opened a ticket for is a serious issue. We created some complex logic, using about 8 hours of a developer’s time. Is there a way to identify the root cause as well as recuperating the logic from backup?
Actually, when you click on the Deploy Button it deploys all the changes in the deployment model, you can see it in the dialogue right before deploying (if you didn’t close it with “do not show again” option)
A deployment model can contain more than one API service and it can include EventHandlers and Timers, and when you deploy an API service it actually deploys all the local changes in the model, items with local changes are marked with green colour
I believe we have to improve the deployment process to make it more clear, we will discuss it with the team, and/or if you’ve got any suggestions we will be glad to hear that
The local changes are stored in the local storage, and after deployment they should not be removed, so could you please check the Changelog on both PC where you did changes for this timer
@vladimir-upirov This is concerning. What is the best practice to have more than one users on the platform. Since you have features around team members and permissions, is there a suggested way to work in parallel as a team?
All our development teams have their own rules on how/when deploying CloudCode/UIBuilder logic, and as far as I know we haven’t such a problem for today.
Deploying the entire model is highly necessary because some API services/methods might require changes in other services/methods, so each team takes it into account when working together on the same project
For now, I can see only one option: it is verifying what exactly is going to be deployed manually.
I guess we will add information about that into the confirmation popup and remove the “do not show again” option, but this requires a discussion with the team
So there is no option to deploy part of the model, or to segment our development into more than one parts? What do other teams do? Deploy once a day? @vladimir-upirov
How do you test new logic without deploying it?
no, you can deploy only all changes for a specific deployment model
What do other teams do?
There are different projects, generally, it is a UIBuilder app with CloudCode
Deploy once a day?
I do not think so, I believe they deploy many times a day
How do you test new logic without deploying it?
Actually, you can’t test without deploying
When you talk about different projects, deployment models, is this the same as different apps? Or is it possible to segment different models/projects within an app?
We have a sandbox app on the springboard plan, is there a way we can use this with the app sync function in order to have a smooth workflow?
This is an important discussion. That’s why I want to share my experience.
I’m deploying cloud code from a local node.js project from my PC. Testing without deploying is possible by using the remote debugging feature.
Currently, I’m the only cloud code developer, but I’m also looking for a way to distribute responsibilities. I see no way of doing it, because there is always a full deployment. Maybe the locally installed SDK can be improved to only deploy local resources which have been changed since last deployment. An integration with Git might be a way to go for you. I’m using Git as my version control.
You have this separation of concerns called “model”. Different developers can deploy independently into different models. What is missing is to merge different models into a productive one, which might happen semi-automatically.
Just my thoughts …
Regards
Thanks @Klaas_Klever for sharing…I am glad to see that there is a potential way forward. Alas, our team are not full developpers, we are low code developpers and do not use node.js, SDKs or Git, for now. We use the Codeless Logic in Backendless exclusively.
Do you have something to recomment as a temporary way of working, or team organization. We have 6 people working on the same app at the moment, and the team is growing.
Hi @Andreas_Marinopoulos ,
As I wanted to reflect in my comment above, currently I do not see a reasonable way to do team development on Backendless in a reliable way. This is at first not related to creating “Codeless Logic”, or “Code Logic”. Both ways create development artifacts, which have to be managed consistently within a team.
By deploying from my local node.js project, I have the “small” advantage that I can choose my source code repository to be Git which offers a solid version control and provides a way to do team development. The backendless code repository is the repo which then can hold the final, consolidated productive code. Git provides means to consolidate code within a team before deploying to BE.
What I’m looking into now is to create a test/dev app which receives a first consolidated code deployment, then run tests and then use the BE merge feature to merge into the productive app.
My hope is, that at some point I don’t need a second app, but the Backendless team is enabling somehow to use different “models”.
This was about the backend code side of the house. For the frontend, I’m in the same situation as you for the backend, because there is no way to version control the frontend sources within a team setting. Also, working on frontend sources with UI Builder simultaneously with multiple team member is not possible/dangerous.
Hope this helps
On the Backend, it is also what I am thinking.
Since each team member has completed the Missions and has a free Springbroad Plan account, my thought currently is to connect one sandbox per team member, as per the example below.
Each team member could build/deploy/test codeless logic on their own “app”. When it is ready, we could possibly use Backendless App-To-App Deployment feature to sync to the main app, a bit like what you refer to Git doing.
I am not sure if this is possible though.
On the front end, we do not have more than one person working on a single page. So it is easier to use the non-published page while testing, then deploy once per day.
@vladimir-upirov I would really appreciate your input here as this is extremely important. I need to find a solution immediately as we are starting to scale the team on top of Backendless, else I need to shift our strategy.
@mark-piller I am sure you are very busy on more important topics but if there is anything you can share on product vision around team development, it would really calm me down.
Regards,
Andreas
@Andreas_Marinopoulos we restored two backups and put them both to https://develop.backendless.com/app/brilliant_grades/files/backups
However, I can see that timer was changed Tue, 24 May 2022 11:33:36 GMT, it seems like they haven’t changed at yesterday 15:00 UTC
@vladimir-upirov thanks, this is very helpful. I will check and see if we need a backup from 11:34 GMT!
First (sorry for the beginner question), is there a way to visualize these backups in the Codeless canvas?
@vladimir-upirov @stanislaw.grin even if we can’t fully resolve the issue right now, I would love to get a reply asap on the below so as to understand if we need to rewrite the logic (a painful process) or not.
You can take the xml file of the required timer from the backups folder (you can find it in /backups/servercode-15-00/CODELESS/default/PRODUCTION/timers) and add this xml file to the servercode folder (/servercode/CODELESS/default/PRODUCTION/timers).
But make sure that you rename the file in the servercode folder so that you don’t break the logic of the timer which is there now. Or, as another option, just create a new timer with a different name and put the xml data of the timer from the backups folder there.
Regards,
Marina
One more question. I would like to clarify the below:
When I click deploy on a backend Codeless Method, does the entire app deploy? What is a specific deployment model? Are each of the “folders” or API services different deployment models or can I make it so that each API service is a different one? Thanks
