google / clasp

🔗 Command Line Apps Script Projects
https://developers.google.com/apps-script/guides/clasp
Apache License 2.0
4.59k stars 428 forks source link

Workflow for multiple devs working in one project #921

Open rmlevangelio opened 2 years ago

rmlevangelio commented 2 years ago

The scenario is that in my team, we want to have a good developer workflow for Apps scripts project. Then we decided to use clasp with Typescript on it.

When we run clasp push, the .ts files get transformed in .gs files in scripts.google.com.

If there are multiple devs working on one project and do push simultaneously, I'm pretty sure the first push will be overwritten by the second push and we will lose the progress.

Can you recommend a good developer workflow in this type of scenario?

imthenachoman commented 2 years ago

Use GitHub or another repo. Everyone works out of the repo and some kind of action/automation on the repo will push to GAS.

rmlevangelio commented 2 years ago

@imthenachoman

I don't think you understand the question. Of course we use github for version control.

As mentioned above, we use typescript compiler for clasp so that we don't need to deal with google apps script. When we run clasp push, it transforming the .ts files into .gs files and pushed into scripts.google.com.

So if we are multiple devs working at the same time, obviously we cannot use clasp pull since it will pull the gs files. and of course we also don't want to make pull request with our changes everytime we wanted to test it.

imthenachoman commented 2 years ago

That's why I am saying to use GitHub/GitLab or some other source code repo in the middle.

Everyone pushes/pulls from the repo.

One person pulls from the repo and pushes with clasp.

Nu11u5 commented 2 years ago

GAS should be treated only as a deployment target.

If individual developers need to test code they can configure their own GAS project file and push to that. If the GAS project is linked to a GCP project, all "copies" can be linked to the same GCP project if needed.

ghost commented 2 years ago

Hello Everyone, I have the same issue, unfortunate you can have different devs for a same project, but each push request does overwrite in all files in apps script. It would be better we have the possibility to do pull request for separate, I mean for spared files without overwrite all project in app script.

imthenachoman commented 2 years ago

Hello Everyone, I have the same issue, unfortunate you can have different devs for a same project, but each push request does overwrite in all files in apps script. It would be better we have the possibility to do pull request for separate, I mean for spared files without overwrite all project in app script.

These are limitations with Google Apps Script, not clasp.

schulzj01 commented 2 years ago

Hello Everyone, I have the same issue, unfortunate you can have different devs for a same project, but each push request does overwrite in all files in apps script. It would be better we have the possibility to do pull request for separate, I mean for spared files without overwrite all project in app script.

We have a multi-developer application and here's how we handle this.

  1. Set up each developer with their own GAS project.
  2. Each developer pulls from the git repo.
  3. Each developer creates a .clasp.json file which is different for each developer, and adds .clasp.json to their .gitignore file.
  4. Developers would test off their separate GAS project, finalize changes, and then push back to the git repo.
  5. Once you're ready to deploy, create a separate GAS project, push your repo code, and create the deployment from that.
  6. Subsequent deployments run off the project created in the previous step.
rnsharma10 commented 1 year ago

Adding to comment of schulzj01 We have 2 different folders for this whole process,

  1. Dev folder with different .clasp.json file content as per the developer locally.
  2. Test folder with same .clasp.json file content for all developers so anyone who pushes code in this will be pushing to same test gas project.

The only downside we see in this is copy pasting files/code from dev folder to test folder but that is once in a week kind of activity so it's managable for us to use this approach.