In our previous blog in this series, we reviewed the benefits of using a live staging model and the blue/green release strategy whereby continuous and automatic deployment is in the users’ hands.
In today’s application-oriented market, your DevOps team’s ability to appropriately flow along the development and deployment lifecycle directly affects your business. With multiple cloud providers and many ways to work with virtual computing, there’s a plethora of technologies and products created to help you with your CI/CD pipeline. So, when you talk about CI/CD, people usually think about the tools. The reality is that creating a scalable CI/CD pipeline is harder than it looks and the main issues to consider are actually the people and the processes you choose to work with.
What we found while creating Colony is that the inefficient coordination of teams and thinking processes are often the downfall of a great idea. When we started to think how to solve the problem not based on the products available, but instead on the way our unique teams effectively work together, we made progress.
The People
Our Colony team is made from 5 major sub-teams: design, development, testing, release, and writers. Product developers and product UI/UX designers work together to create a Feature Design. The SCRUM leader and developers create the feature according to that design. The testing team works on the feature branch with automated tests. Features that pass these tests are moved to the Master Branch. The release pipeline performs different automated tests in order to deploy to production according to a blue/green strategy. Along the way, marketing writers check that the business aims are being met according to the product plan, and the technical writers document the feature according to its use-cases (as described by the developers and marketing writers) and write how it actually works step-by-step.
The marketing and sales teams require environments so they can demo the software to potential customers. The product teams need to see the UI so they can check it comes across to the user in the intended way. The development team needs access to the front and back-end of the product so they can do their work. The testers need access to environments to allow them to make sure everything works the way an average user would want. The release team assures that the blue/green release versions pass sanity checks.
The Process and Solution
From the side, this development process appears straight-forward. But as we discussed in the previous blog, software development is an iterative process constantly editing, testing, developing corrections, and then pushing forward product features. With all the back-looping, inefficient team coordination can become a significant problem. By using multiple dynamic environments for teams and their individuals, DevOps teams can critically decide which tasks are worth automating and can develop and solve according to what makes most creative sense to them. They aren’t bottlenecked by their colleagues, so they can move efficiently at their pace, iterate, and correct along the CI/CD pipeline.
Environment as a Service is the answer, as it allows both the application and the environment to run simultaneously and undergo version control. Environments can be spun up and torn down as needed (self-service). This gives the company the ability to control the cost and security in a tidy package.
The best way to solve these issues is to think this way from the very beginning. CloudShell Colony offers the facility for each of your DevOps sub-teams from start to finish. It’s working for us at Quali, and we look forward to getting it working for you.
