New answers tagged

1

Well, binary files aren't supposed to be part of your repository indeed. As an alternative scenario, you should probably be looking at deploying code from repo to hosting platform and static files (images/documents/...) to another destination, a CDN for example. Another alternative for web might be ton include some of the images as base64 encoded strings in ...


2

You can release to a QA 'trunk' before going to the release trunk. This lets you get more testing in, and lets you promote good integrated builds to a release. The difficulty comes if you find a bug, you have to decide either to fix it and get it integrated, or to cherry-pick those branches that passed onto the release trunk, skipping the feature with the ...


1

Your strategy is sound. I would only offer to consider expanding the "Transitional Schema" into a complete set of "transaction tables". With transaction tables, SELECTs (queries) are performed against the normalized tables in order to assure correctness. But all database INSERTs, UPDATEs, and DELETEs are always written to the denormalized transaction ...


3

It sounds like what you are really looking for is not so much High Availability as you would need Continuous Availability. Essentially your plan will work but you seem to have noticed that the major flaw in your setup is that database schema changes in a release could result in either downtime or failure of still available node to operate correctly. ...


5

Packaging means packaging. Software development in a nutshell: First, you plan your project. What does it need to do? How will it do it? Who will make it? And when? Then you design the system. Lots of diagrams. And documentation! Then you implement it. It's coding time, batman. Now you can build it. In some languages/paradigms, that means compiling and ...


0

Yes. For example with a nodejs application a developer will download the various dependencies and build them from source (the one command npm install will do that for all dependencies, as long as none are too weird). However when deploying to the wild the developer will probably bundle up all the files he has downloaded into a tarball or something fancier. ...


3

There are many reasons a customer may be reticent to push on to the latest software version. Some reasons I've come across: Known quantity The customer may simply be very happy with a legacy version. They know all the foibles, how to fix things should they go wrong and how to get the very best out of the software. Time The customer may not have time to ...


2

Why would you use Windows 7, while Microsoft released newer versions meanwhile? Similarly, one can decide to keep an older version of Linux, or an older version of Python. Some factors one should take in account : The price of the new version. The operations cost of upgrading. The time needed to learn the new version. Backwards compatibility: if you have ...


4

There can be several reasons to stay with an older release: New releases may cost money for a new license. If the older release is sufficient, why spend the money? New releases may cost money and/or time (a.k.a. money) to learn and/or install. Again, why bother if the older release works? New releases may break things. This may be intentional (removing ...


8

Older versions can bring stability to a software deployment. New versions of software may introduce new bugs, potentially crippling bugs. For anything mission-critical, only battle-tested software should be deployed in order to reduce risk. If you want the latest and greatest then put it on a desktop or other non-critical system. This is the thought ...


2

You deploy the branch you need to where you need to. Now, obviously you aren't going to deploy a feature branch to production. But deploying the latest build from Master to development shouldn't be a problem. The development branch in git-flow is about being the mainline - that from which the normal process has you branching off of and merging too. The ...



Top 50 recent answers are included