When would I use additional phases in the deployment pipeline of a web project?

Question

All of my projects up to this point have been solo (I develop single page web applications). I've always used an IDE which automatically uploads changes to a test Amazon EC2 server over SFTP and I simply refresh my browser page to see the changes. Then when Ive got a stable result, I upload the changes to my production EC2 server, and the product is updated.

Recently I started working on a group project, so I needed to make sure we didn't over-write the changes of others, so I changed my workflow:

1. Collaborators write code in the IDE
2. IDE automatically syncs those files to their local Github storage for our project
3. They commit those files to the online Github project
4. AWS CodePipeline pulls those commits onto a test AWS Elastic Beanstalk environment
5. We can test those changes
6. When satisfied we sync the project to our production AWS EB environment.

That seems as complex as I would want my workflow to get.

But when researching deployment solutions, I found this chart showing many more steps in the deployment process:

The AWS marketing material for Code Pipeline demonstrates extensive possibilities in deployment phases, and I feel like I've only scratched the surface, but I can't think of why I would want to have any more steps than I do now. Can someone explain when or why I would want to use these various other steps in deployment of a single page web application?

Obviously I'm not working on a large scale project, but I'm interested in knowing what kinds of projects and situations would require me / my team to use these various aspects of a deployment pipeline.

Answer 1

You use additional phases when you need to.

That's not just a glib answer. Each additional phase can solve some problems but also adds costs, in terms of money or time people need to manage the process. Which phases you need depends on what problems you're seeing in your own development.

The diagram you showed doesn't list phases, really. It lists concerns.

For example, collaboration. If you have three people working on something, it's not too hard to stay in sync. If you have thirty people working on something, you start wanting a more dedicated collaboration tool. You might want Slack to keep the teams talking when they're all over the country. You might want each team to have their own packages that get combined into a whole. So you need some internal package repository. You might have a million users, and a tiny bug could still affect tens of thousands of people, so you'll want good automated testing to try to reduce that possibility. You might need to spin up a hundred or a thousand servers to handle the load of your new, exciting instagram replacement, so now you need something to manage environment provisioning and configuration.

As a team gets larger and as the code affects more users, these things begin to become important. For example, Netflix has a gajillion users and has a gajillion servers running (mostly on Amazon AWS last I checked). So now they need a lot more of these things than they did when it was three programmers and 10 users.

So how do you know when you need something? Wait until you have a problem you can articulate. "I've now got thirty people working on my SPA and it's really hard to make sure everything is stable to release." Or "I have this thing that changes all the time, and this thing that hardly ever changes, but each time I release I have to deploy a giant Webpacked javascript file that needs to get cached in every browser. Wouldn't it be nice to split that stuff up?"

Answer 2

thanks for the great question and for using the DevOps Generator as a guide for your deployment endeavors. My name is Sunil Mavadia, Director of Customer Success at XebiaLabs and I wanted to answer your question: Can someone explain when or why I would want to use these various other steps in deployment of a single page web application?

A single web application is probably the easiest to deploy to a target server (or vm). This diagram shows the various stages of deployment when the applications are much more complex with middleware such as messaging systems, business rules engines, databases and infrastructure changes. In addition to these changes, the need for stop-gap measures during the release cycle is always prevalent. For example, having some critical checks occur (manual or automated) before code gets deployed to production.

With this in mind, YOU wouldn’t want to use the various other steps right now, but as your application gets more complex through the incorporation of other technologies, that is when you will realize the potential need for these various other stages/steps.

Hope this helps!