5 ms·

I guess this is not intended to be your "main" repository? Something about the idea of deploying on push to master seems off to me. I have been thinking about

by masto 13y ago

I guess this is not intended to be your "main" repository? Something about the idea of deploying on push to master seems off to me. I have been thinking about doing this myself, but it would either be a special release branch or a tag that would trigger the deployment. However, I'm still not convinced it's a good idea; I think it's the wrong tool for the job. My preference is to have a continuous integration server produce and archive builds, and a separate tool for promoting those builds through the development/qa/staging/production pipeline. Using your source control tool for deployment is like a badly structured class that tries to do multiple unrelated things and suffers from tight coupling. Source control, build systems, and deployment tools should be independent, with clean interfaces between them. The component responsible for deploying a build shouldn't care where it came from or how it was built.

schrodinger 13y ago
Don't use it as your main repository, that's all. Store your true history in another location, and use this as a way to reliably sync your files to the hosting environment. Setting up a CI environment with automated deploys is probably better, but this is great for small projects that don't warrant that level of configuration. Also, if you do go the CI route, this could just be how the final step of copying files works, rather than rsync or something.
ImJasonH 13y ago
Alternatively, deploy to a non-default serving version of the app. Then, when you push/deploy, you can go to the non-default version, check it's right, then promote it to default. This flow isn't as smooth as it could be, certainly, but we're hoping it could be useful for small teams or new users. And we'd love to hear your ideas about how to make this even more useful, this is an area under very active development (thus the Preview label)

by masto 13y ago

schrodinger 13y ago

Don't use it as your main repository, that's all. Store your true history in another location, and use this as a way to reliably sync your files to the hosting environment. Setting up a CI environment with automated deploys is probably better, but this is great for small projects that don't warrant that level of configuration. Also, if you do go the CI route, this could just be how the final step of copying files works, rather than rsync or something.

ImJasonH 13y ago

Alternatively, deploy to a non-default serving version of the app. Then, when you push/deploy, you can go to the non-default version, check it's right, then promote it to default. This flow isn't as smooth as it could be, certainly, but we're hoping it could be useful for small teams or new users. And we'd love to hear your ideas about how to make this even more useful, this is an area under very active development (thus the Preview label)