0

I recently joined a SaaS company that has so far not been using source control track and maintain their development, instead just separately working on their own portions of a given client's codebase. In an effort to help and positively contribute, I've begun using git on my own contributions and want to bring more (in the future, all) of my coworkers into the VCS fold.

My question comes from the complex nature of the development environment(s) we write in, and the best-practices for version controlling it. I'll give a description of the set-up and then present the specific questions afterwards.

Set-up:

The business is built on Archibus. We deploy, support, and customize each customer's install. Each customer has a dedicated server pair, which hosts all of the production code and the in-testing pre-production code. In addition to this, we host our own copy, and each developer either access that through a remote desktop client or runs a copy of the server locally to make development easier.

Into this, I've tried to inject some VCS by shifting the burden of code changes from within my local install to a development directory where I manage my npm transpilation stack: I write in my directory and then run a powershell script that calls npm run build and then moves all necessary files to their correct folders within the server.

For moving the changes to production, I created an empty branch that lives in the server and only tracks the transpiled code. When a feature or fix is ready, I commit and tag it, push it to my repo, and then pull the changes to prod-test (and later production), without carrying with it any leftovers from node or my development system.

This has worked fine until I was tasked with developing a new Java module within the complex internal structure itself, which will by necessity include changes to a large number of discrete files across multiple sub-directories, including multiple jars. Now I can't just write the code elsewhere and then move it in when necessary unless I'm willing to write some extremely annoying additions to my Powershell script and rework the Eclipse dependencies.

But if I want to track the entire project folder, that would track over 30k files across 4.5k directories, sitting at around 1 gig. Additionally, I'd lose the ease of tracking my ES6 code separately from the production-ready transpiled ES4 code.

Questions:

  • What are the best-practices for managing large code-bases like this?
    • Do I need to bite the bullet and just include the entire structure in my repository?
    • Do I expand the complexity of my scripts to move only what needs to be moved when necessary?

If there's more I need to add, please let me know. This is my first major project in software, and I'm feeling anxious to get it right.

6
  • 2
    So the way you deploy to production is with a "get latest" against (a specially structured part of) the code repository, and that is all?
    – John Wu
    Commented Jul 17, 2017 at 19:12
  • When I do, yes. When another developer deploys, they copy-paste their copy of the changed file(s) to the prod-test server. Commented Jul 17, 2017 at 20:01
  • If you only deploy files that are changed, how would you do something like roll back to a previous version, or build out a new environment from scratch?
    – John Wu
    Commented Jul 17, 2017 at 20:05
  • Before I started, they had no real way to save previous versions. Now, for the projects I am on, I have all of my versions "saved" through git and can roll back by reverting to the necessary commit. Commented Jul 17, 2017 at 20:22
  • 1
    Seems to me that would work for rolling back a changed file to a version that had been changed a little less. But it would not roll back a newly changed file to its unchanged version-- in fact, it might even remove it when source control syncs your working folder, if you are only storing modified files. I think your deployment paradigm is very unusual. Are you open to changing to something more traditional (e.g. Samuel's answer)?
    – John Wu
    Commented Jul 17, 2017 at 20:25

1 Answer 1

4

Do I need to bite the bullet and just include the entire structure in my repository?

Git supports very large repositories no problem. You can decide which parts of your large project you want to include in the repository, or just do the whole thing.

Do I expand the complexity of my scripts to move only what needs to be moved when necessary?

I think you should better separate the notion of a source file from a prepared file. You should have a build script (ideally run by automated CI) that checks out your source repository, builds the software (i.e. compile/bundle/transpile), runs any automated tests, and publishes the packaged software somewhere. Ideally the compiled form of the app is not tracked by Git because Git is not really designed for storing build artifacts. The build artifacts should be in your .gitignore file. Instead you should publish your build artifacts to a repository like Nexus.

At deployment time, you pull deployment artifacts from your artifact repository, and place them in the right folders using a deployment script.

2
  • additional note: git submodules might be a very viable option to separate different components of the application.
    – Vogel612
    Commented Jul 18, 2017 at 9:46
  • Sadly, some elements of this answer (Nexus) can't be implemented at my current job, but the rest is rock solid. Thanks so much for the ideas! Commented Jul 18, 2017 at 16:42

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.