Web based PDF Flyer Management
Programing: “CONTINUOUS DEPLOYMENT” vs “FEATURE BRANCH”
MVI’s newly-adopted software development methodology is known as “continuous deployment.” Under continuous deployment, a developer writes new code in discrete little chunks and places each chunk into a testing line of software shared by all MVI developers. The testing line is called a “trunk” a standard system utilized in the technology industry. These newly-added chunks of code are subjected to an ostentatious series of robotic tests designed to find bugs. Once the code passes the tests, it is merged and cataloged which displays to project managers what features are tested and ready to go live.
MVI’s prior system of software development was more traditional, involving software “branches” forked off from the trunk and developed in parallel over a period of time. A developer would finish a batch of code equivalent to some feature and then this coded feature would be tested on the parallel offline trunk. Once merged into trunk, the feature must be tested to ensure it did not break any of the other code. Bugs and outright broken software are common under “feature branch” system, since typically multiple batches of code, each written in isolation by a separate developer, are combined into the trunk at once. To avoid such problems MVI project managers tended to tightly limit the number and scope of new features mashed together each month, slowing down a company’s development cycle.
Shifting from feature branch based development to the new continuous deployment system required halting some development for months as MVI trained staff, migrated old code, and built out the automated tools it needed to make the new system work.
MVI is hardly the only company to use continuous deployment; Linkedin did this in 2012. But MVI customers required more speed and MVI staff had experience with the system from prior gigs. But MVI’s big switch to continuous deployment has been linked to very concrete and visible financial success, helping lend credence to the practice and potentially helping to accelerate the delivery of software across the breast of our client development projects.
For MVI, the move to continuous deployment was about solving concrete problems rather than spreading a doctrine. We had to go from this model where developers were developing their code in relative isolation. We wanted to be at the point where, as soon as they completed checking their code and it passed testing phases, it was released. All features in the trunk must be releasable at any point in time, and if it’s not releasable it’s just as significant as a site emergency. Stop all forward software development and everyone is all hands on deck to get trunk fixed.
The addition of this process was not an experiment but a proven practice that is seldom used by smaller web development companies. MVI made this commitment to create a larger future with advanced techniques.