Continuous delivery for ecommerce development

Modern web development requires modern solutions. That includes workflows and approaches that employ best practices and deliver precise results. Continuous delivery is the bedrock of Acro Commerce’s purpose-driven development method and results in development projects being delivered to market fast. Read on to find out how it all works.

How web developers build and release code is constantly changing as the tools we use become more intelligent and efficient. It was commonplace to write code not long ago and then manually move the new or modified files up a testing or production server. This process worked but was slow, and there was a high degree of risk for breaking changes.

As the web evolved and collaboration tools and methodologies developed, a modern workflow took shape considerably different from before. This article will discuss the modern approach of continuous delivery (CD) and how we use it at Acro Commerce for Agile ecommerce web development.

It should be noted right off the bat that a development cycle will change from one organization to the next, and possibly even project to project, so what I discuss here might not be exactly the same as what you would find with another development firm.

Continuous delivery

Before I get to continuous delivery, let’s take a quick look at how a project is structured so that we can see where the continuous delivery approach fits within the overall project. Acro Commerce has published our iterative approach to development, our development cycle, if you will. We call it the Acro Purpose Driven Development Method as part of our project management services. This method outlines, at a high level, the basic idea of how we work towards a successful end goal. It breaks down the development cycle into a series of easily digestible phases and explains some of the activities in each step. Not every stage is always required, but it provides our clients and us with a path to follow with each project, big or small.

While it’s easy to write “what we do,” actually doing it efficiently is a whole other story. This is where the pieces of continuous deployment come in.

Mixing in Agile principles

Seeing the phases of our development cycle is one thing, but pulling it off is another. From start to finish, we often follow an approach that is founded in Agile values and principles.

Taking a SCRUM-like approach, we work towards our end goal through a series of short sprints. A sprint is a grouping of tasks where each task assigns effort points to more easily understand how much work can be completed within a given timeline. Sprints get completed in sequence until the end goal is met and the changes are taken live.

Unlike waterfall projects, where a job is worked on until it’s done, sprints allow smaller segments of the project to be completed iteratively, which gives a better indication of the overall completed status of the project. This framework also makes it easier to enable on-the-fly changes in direction or timeline changes should an unforeseen event occur. It ensures that progress is always being made continuously in whatever direction is required.

Of course, not every project requires this style of project management. The method of project management used is decided on a project-per-project basis and is even sometimes determined by the client (i.e. if there is a deeper collaboration between our teams and they have a project management style that works for them).

Mixing in DevOps

From development through to launch, we take a DevOps approach to automate and monitor the development cycle as much as possible. DevOps provides us with many fantastic tools that make our lives easier and ensure a quality results. When a developer working on a sprint pushes some code, our DevOps setup puts that code through a series of code quality tests and checks automatically.

If a test fails, the pipeline stops, and the developer gets useful information for correcting the issues. Breaking changes are found well before they ever make it to a critical point. Coding standards check to ensure that the code produced is of high quality.

When all tests pass successfully, the entire site code, including the change, is built and sent to one or more staging environments that mimic the live site exactly. This is where further automated testing and other quality assurance (QA) activities, such as manual testing and user/client acceptance reviews, happen. With all of the boxes checked, the new code is merged and can be taken live with the click of a button.

Bringing it together

All of the approaches shown above make up the concept of continuous delivery. You may have heard of similar terminology out there, such as “continuous integration” and “continuous deployment.” These terms explain a very similar methodology but with some slight variances.

• Continuous integration
  Continuous integration is a term that does most of what I’ve outlined in the DevOps section above. It’s a method of using DevOps tooling to test code automatically when a developer pushes a change.
• Continuous delivery
  Continuous delivery takes continuous integration a step further by adding automation to the delivery of code to staging or production servers. So, after all tests are passed, the deployment process to a server can be triggered with the click of a button.
• Continuous deployment
  Continuous deployment is the same as continuous delivery except that the deployment process is fully automated and any manual process or testing is removed. Deployments to the live environment are triggered automatically when all automated testing has passed. This is great for documentation and internal software tools but doesn’t really work well for web development, where often there are frontend elements that need to be manually tested or signed off on by QA and creative teams.

Right now, continuous delivery is the cream of the crop in web development. It’s sophisticated and allows for a very high degree of quality because of the level of automated testing achieved. It finds potential flaws and supports the developers in writing good code. This also serves as training in a way. It saves time, allowing project sprints to progress more quickly with greater success. It allows the client to spend their money more effectively and to react quickly to a changing market. Frankly, it’s just a great way to get things done.

Continuous delivery is best for ongoing development

Another benefit to continuous delivery is that you are constantly making small improvements to your website and commerce architecture on an ongoing basis instead of pushing infrequent large changes. Small improvements are easier to test, easier for your regular site visitors to adapt to (if the change is visual or involves modifying the user interface), and easier to roll back or apply hotfixes should a breaking change somehow make it through.

Because improvements are made in smaller increments, continuous delivery is ideal for organizations requiring a dynamic and flexible website with constant changes. A change could be anything from modifying layouts, adding new calls to action, changing product types, performing framework or platform updates, fixing bugs, enhancing security, adding features, building integrations and automation, increasing performance, refining the customer experience, etc. Continuous delivery gives organizations the means to plot their development path adaptively and flexibly with a rapid timeline.

Continuous delivery and you

Is your organization struggling to get your ecommerce site where you need it to be? Maybe a continuous delivery is an approach that you need to make happen. Acro Commerce is an ecommerce consultancy and development firm that can help. We use these methodologies in our toolset to empower clients with the freedom to control their development roadmap and develop solutions tailored to their business needs.

---

_{Editor’s Note: This article was originally published on August 19, 2019, and has been updated for freshness, accuracy and comprehensiveness.}