Speed of innovation is what differentiates leading businesses in today’s competitive environment. Developers pioneering at the edge are always looking for ways to iterate faster and more reliably. Continuous integration, continuous delivery, and continuous deployment are the industry baseline for rapid innovation at the edge.
Continuous deployment (CD) is an extension of continuous integration and is used to reduce cycle and lead time time in between writing a new line of code, and that code running in front of users in production. To achieve continuous deployment, developers depend on infrastructure that runs and instruments the pipeline of automated steps that change the code running in production. This ensures that every change is predicted to work, the code change applies successfully, and the code behaves as expected after deployment.
Benefits of Adopting Continuous Deployment
Over the last decade, Continuous Deployment has emerged as the industry standard for making software changes because:
- It reduces the change failure rate. Teams that deploy multiple times a day, with less than 24 hours of lead time, experience less degraded service, and fewer remediations.
- It reduces the time to restore service when defects are introduced. Teams that deploy multiple times a day restore service at least 24x faster than teams who deploy at most once a week.
- It unblocks innovation. Organizations that embrace Continuous Deployment practices perform better on profitability, operating efficiency, and market share.
- It reduces the delay on ROI. By getting code running in front of users faster, CD helps organizations find product/market fit faster.
Continuous Deployment vs Continuous Delivery
We often see the terms Continuous Delivery and Continuous Deployment used interchangeably, but there is an important distinction between the two to call out.
Continuous Deployment automates change promotion from one stage of the pipeline to the next without the need for human intervention. While this drastically increases the pace of iteration, it also initially carries more risk in pushing errors to production.
Continuous Delivery requires human intervention to promote changes, typically at the last step, but often in subsequent stages.
Both types of CD can be applied to applications and infrastructure. In fact, while CD is often discussed in the context of application lifecyles, there is a growing body of research to show CD’s impact on delivering and deploying infrastructure services continuously, including lowering defect rates and improving software quality for applications.
Building CD into Edge Configuration Management
In distributed compute architectures, deploying and scaling workloads can become much more complicated. Most development teams would rather focus on writing and shipping code that delivers value to users, than complex networks or infrastructure.
Key Principles
To manage changes to your edge configuration through a CD pipeline successfully, there are three key principles worth adhering to:
- Optimize for fast feedback. Identify steps within the pipeline that need optimizing by tracking execution time on individual stages. From the time you push a change to version control to making the change live should take no longer than five minutes. Fast feedback is important for quickly ensuring your changes meet business needs and cutting out technical debt and unnecessary costs.
- Chunk your changes, test immediately. Instead of changing multiple things in batches and then testing for the effect, interleave the changes and tests, and stop execution immediately if the tests fail. By turning changes into small, verifiable units, you lessen the risk factor.
- Push all changes through the pipeline. You lose the benefits you’re striving for if you accommodate changes outside the process.
Breaking Down the Pipeline
- Push - An engineer issues a change to the configuration and pushes it to a repository. The changes can either be reviewed through an established process or pushed directly into master.
- Detect and trigger - The repository is either regularly polled or a hosted version control system, such as GitHub, calls out via a webhook to detect the change and trigger a build.
- Build artifacts - The build establishes dependencies and builds software artifacts (if any) that will be deployed further along the pipeline.
- Build infrastructure - The build communicates with an IaaS system in order to build the required network, compute, storage and load balancing structure.
- Orchestrate infrastructure - The build uses a configuration management tool to provide the service by stringing together the provisioned infrastructure.
Testing: Testing after each change is essential to ensure that the CD has been effectively implemented. “Change one, test one” is a useful rule of thumb. Make all your changes then immediately test them. This means you’ll get fast feedback if a change fails the test, allowing you to automatically halt any other changes until you debug and fix the problem.
What to Look for in Edge Workload Management Tooling
As more organizations adopt edge computing architectures, one of the main considerations when evaluating edge workload management tools is how configuration changes are integrated into CI/CD pipelines. Here are some key features to look for:
Granular Control
- Source code management - a correctly configured source code management (SCM) tool will underpin a stable platform for project development, which offers file access management, expedited version control, and natural storage of all essential project files, including the operative code and all linked script libraries, databases and integrated development environment (ICE) configurations. CD systems depend on this kind of in-depth control.
- Configuration as code - configuration as release-ready code will allow you to configure and manage your infrastructure, and leverage your CI pipeline to set up automated workflows, meaning instant configuration changes.
Programmability
- API-first approach - automatically executing changes without relying on human intervention will let you derive the most significant gains from the implementation of CD.
Instant Validation/Invalidation
- Integration into standard development lifecycle workflows is essential.
- Instant rollback when necessary - ensure your edge platform supports instant rollbacks and configuration changes so you don’t end up having to wait for indefinite periods of time and can instead make changes instantly.
Real-Time Visibility
- Quick action requires robust observability tooling: logs, metrics, tracing.
Integration with Popular CI/SCM Tools
- Jenkins - an open source server-based, cross-platform CI tool, offering broad plug-in support for various builds and databases; entirely written in Java and available for public use under a free software license at MIT.
- CircleCI - a commercial command line interface, which has a reputation for ease of use and speed. Used by various high profile clients, including Facebook and Spotify.
- Travis CI - easily syncable with GitHub projects, Travis is a hosted service known for its advanced testing options and range of languages support.
- Bitbucket Pipelines - an integrated CI/CD service built into Bitbucket, with an easy set up, which lets you automate code from test to production. It’s often used in combination with CircleCI, which offers a free container while Bitbucket provides free private repos.
Managed Infrastructure Services
- Eliminate overhead associated with building & orchestrating infrastructure.
- Autoscaling - Confidence in knowing that compute resources will expand and contract to meet performance and cost requirements.
Best-of-breed edge management tools will allow you to focus on constantly identifying and eliminating bottlenecks in your CD pipeline to get your iteration time down. Section’s Edge Compute Platform is built to complement and integrate with your CI/CD workflows.
If you’d like to discuss your specific CD edge needs, chat with a Section engineer.
