9

I'm trying to think of a better way to version control our website projects. Keep in mind I'm only a front-end dev so I don't have a profound knowledge of VCS.

Workflows are changing, and past version control habits become obsolete. The main problem is there are 2 arrays of front-end files for each website.

The dev environment (less files, uncompressed js, images, etc). The build environment, "gulpified" (everything compressed and not readable by humans).

But you can't sell a website with its source files. Well, it feels not quite right.

There's the solution of having 2 repos : one build, one dev, with gulp sending dev files to build directory. But its a hassle to maintain, with small companies I don't think it's that great. It creates a lot of repos, and people have to manage with several repos, sometimes even with one svn repo, problems arise.

So there's also the solution of having 1 repo : the source files and the prod files in the same svn. But then it is needed to remove the source files when the website goes from local dev server to production server (so there are different files in a single repository, based on its location, dev or production..). From what I heard, it's not good

What is the correct way of managing a gulp front-end workflow in regard to version control system ?

Improve this question

1 Answer 1

Reset to default
13

One basic rule of source control is that you need only to put manual written artifacts into the repo (the original source files), everything which can be "compiled" or "generated" does not need to be stored there, because it will produce redundancy. One can (optionally) store intermediate outputs/parts of a build process in a repo (sometimes also called artifacts), when the steps to reproduce them are not fully automatic, or for caching purposes, when the build steps to reproduce the output is slow.

So if you have a fully automated process to generate the production files from your dev source files, you only need put the dev files into source control (together with the scripts for creating the production files). If not, establish such a process. Make sure noone has to fiddle around with the production files manually after they have been generated from the source. If you want to deploy "directly" from your VCS, make sure you have a deploy script which pulls the dev source files out of source control, does the "gulpification" and transfers the resulting files over to production in one step.

Of course, if you want to use source control also as a "poor mans backup" or as a cache for your production files, you can set up a second repo for this purpose and put there a copy of the production file structure after generation. This repo will not serve for development, and after it is set up, you should not have to maintain it manually. So make sure there will be no manual steps involved for making backups into this "prod repo" - include the necessary steps into the deploy script which makes the backup automatically. Think about adding a separate backup script if you cannot prohibit manual changes to production after deployment. That way, you can keep the process maintainable even if you have limited resources.

And yes, this should be a strictly separated, second repo, because it has a completely different purpose and a different life cycle than you dev repo. You use it only for backups, not for source control, which is a different process.

Improve this answer
9
  • does that mean when the site goes to production, it's needed to build it from the production server ? or maybe just host the build (which is not versionned then)
    – Antonin Cezard
    Commented Sep 9, 2015 at 16:43
  • @topleft: From the "production server"? Not necessarily, the source code is in the repo, you can build it from everywhere where you have access to source control and to the production server's file system. So whereever you prefer, from a dev machine, from a decicated build machine, or maybe directly on the prod machine. But see also my added paragraph after you wrote your comment.
    – Doc Brown
    Commented Sep 9, 2015 at 16:53
  • 3
    Your wording is confusing. "Artifacts" frequently refers to the output of compilers or generators, not the input.
    – Daenyth
    Commented Sep 9, 2015 at 18:49
  • It is not exactly always true: for bootstrapped compilers, you may need to put generated files under VCS. A typical example is Ocaml's bytecode boot/ocamlc or GCC MELT melt/generated/*.cc files
    – Basile Starynkevitch
    Commented Sep 9, 2015 at 20:21
  • 1
    @Daenyth: AFAIK the word artifact means primarily manually produced parts in software development. You are correct that in some contexts people speak of "build artifacts", because what the compiler produces is indirectly a result of the manual programming action.
    – Doc Brown
    Commented Sep 10, 2015 at 5:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.