Advice on new git / deployment workflow

Question

I work with a small team that until recently didn't use source control. I'm working on the layout of our development/deployment workflow with git. I would appreciate and advice or insight you might have.

I'll spare you the details but we are basically using the git flow branching model and deploying with a remote pointed to a bare repo on the production server with a post-recieve hook. My question is with a larger project we have been developing. This is an application that will have many instances that will need to be able to update from the master branch of the applications repo but also have it's own set of unique files (front end project specific files).

I'm a little lost and I think it may be because I have the deployment scheme a little off. I've heard many people say "git isn't for deployment" and an equal number saying the opposite. The system works great for us currently pushing to the remote that deploys it based on that server's post-receive hook.

One deployment idea we have is to have a list of branches from the App's master that will have it's own 'projectA-master' and 'projectA-develop' branches that will follow our current git workflow. This leads us to having MANY branches on the original App repo and that feels wrong. Not to mention it doesn't scale well. We only have four servers slated for deployment but this method is awful when it gets to be 20 or more. That's a deal breaker.

master---A---B---C
   \\ \
    \\ develop--A--B--C
     \\
      \projectA-master--C--D--E
       projectA-develop--C--D--E

Yuck.

Another idea was to have the App repo for development and updates and another repo (maybe App-frontend) that would be specific to each project and have a similar branching model above only not in the original App repo preserving it's code and branches to only core app specific development. Then having both deploy into the remote server.

master(App)---A---B---C---E---F----G
    \                            /  \___
     develop---A---B---C---E----F    ___ Live Instance
                                    /
master(App-frontend)---A---B---C---E
    \                             /
     develop---A---B---C----E----F

This too feels wrong.

I used .gitignore to ignore all of the directories that are project specific but the problem I had there was that my FE files were not being source controlled on the remote server, they remained un-tracked.

I don't know how to push updates from the app master repo and not override the custom files on the project specific (remote server repo) level.

So how do you manage a situation like this? You've a product that will have many instances but each instance has client specific front end files. And how is this managed on a large scale of hundreds to thousands of instances and you still need to push out updates/fixes?

I've been all over these and other forums and I've gotten pretty far from not really utilizing git at all. If you have the time I would appreciate some input from those of you more experienced that can tell me what I'm doing wrong and what I'm doing right.

Thank you very much.

Answer 1

Welcome to the world of change management and deployment.

Git - with gitflow is one of the best source control tools out there at the moment for managing the software development side of creating a product. But the key part of that sentence is source control tools.

---

There are several other aspects to the solution you are looking for.

Build Automation - Jenkins, Team City, CruiseControl.NET are examples in this category. These products take code from your source control and compile it into programs, run unit tests, do code analysis and publish artefacts from this build process.

Artefact Respository - Artifactory, Archivia, Nexus are examples of this type of product. These act as versioning stores for the build artifacts. You can request the latest of this build, or specify version 1.35 and get compiled official outputs

Deployment - Chef, Puppet, Salt, CF-Engine are examples that manage the deployment. These tools handle the configuration and installation of the software (and many OS aspects too)

There is a lot of work involved in setting up this kind of environment, but when you are deploying software to large numbers of servers, this is import to do, and to do it with care and precision.

Answer 2

If I understand your needs correctly you want three things:

• Your FE (front end I think) / config files to be tracked in source control (so, git).
• You want different configuration files for different installations.
• You don't want those configuration files shared.

One possible solution that occurs to me is to have different git repositories.
There would be one for the main source code, branches, etc as you have already described.
The other repository (which would need to be in a different directory outside of the main project, though presumably accessible by it) would be a repository that is only for the config files. It is a git repository so has all of the advantages of source control but is not tied to the other repository.

Actually managing this still requires some choices. You might have a default 'template' repo (read only) which is initially cloned and acts as a template, and then have branches for each install within it might be one option.

btw One thing that you may see suggested by others is git submodules. I would advise you avoid them. They certainly seem like a good answer 'in theory' but in practice, at every workplace where I've seen them, they've not worked well at all. The workflow is too different and manual when compared to the main git & branch workflow that is the default at many places.

Answer 3

I think most of your problems will resolve themselves once you distinguish development from deployment.

git flow is a great workflow for development; but the cases in which I would push code to prod straight from source control are extremely limited. Probably only for personal projects or a very alpha-stage startup with no customers.

Once you've got a viable product, it's important to ensure that your codebase runs through some sort of sanity checks before it hits a prod box. As other answers have mentioned, Jenkins, Teamcity, or another CI server is a bare minimum. A continuous inspection tool like SonarQube or Coverity would be even better.

The git push-to-prod workflow also breaks badly when your new release requires dependency upgrades. That's where a config management tool really comes in handy.

To get back to your answer, I would probably maintain the core code – the stuff that doesn't change across vendors – in one repo. Each vendor gets its own vendor-specific repo. Use your CI build to overlay both repos into a common project, and then store the result as its own build artifact.

Let's say you're developing a Salesforce plugin. Store the general code in salesforce-plugin-core. Store the vendor extensions in vendor-a-extensions, vendor-b-extensions, and so on.

Create a CI job for salesforce-vendor-core. Use your CI tool's downstream job trigger mechanism to kick off the vendor-a-extension and vendor-b-extension jobs whenever the core job succeeds. Each vendor job should produce a final, vendor-specific package: something like vendor-a-plugin.jar and vendor-b-plugin.jar.

If you ever decide to become a SaaS provider (and it sounds like you might be), this workflow allows you to quickly push the vendor-specific packages to vendor-specific environments.

Answer 4

Those unique files, are they installation specific? This is usually solved by putting properties in local config files (or in the registry for Windows), making sure these are not overwritten after each update of the application.

If you need central management of these files, you need some kind of datastore to host a config file per instance. You could use git for that, a branch per installation, or just one branch with a folder per installation, but it could also be a simple FTP server or a database. This should be kept separate from the main deployment artifact, since they should not be tagged or branched with the main application.