In today’s world, cloud is the best place to develop consumer facing applications and services. Organisations are heavily investing in development talent to help differentiate from the competition and deliver innovative solutions. Having in-house DevOps capabilities is fast becoming the must have proficiency for any forward-thinking IT department.
To help you understand how to maximise your DevOps capability, ANS DevOps Engineer, Will Dewhurst has put together his DevOps checklist. Read on to find out what you need take your DevOps processes to the next level.
Do you have fully automatic deployments?
Having 100% end-to-end automated deployments is an essential part of good DevOps practices. It enables your development team to quickly iterate, deploy often and have a good general trust in their running code. Deployments can be triggered by events such as commit, pull-request, time-based or manually. It is good practice to also have an automated rollback procedure, just in case something goes wrong.
Do you have zero-downtime deployment?
Having zero-downtime deployment is essential for a seamless user experience and for the release velocity of your DevOps team. There is a lot of work that goes into supporting rolling upgrades like multiple application instances, load-balancers, decoupled state management, CI (Continuous Integration)/CD (Continuous Deployment) and others.
Do you have release management documentation?
As good as a release management process is, it must be well documented and made available for the whole development team. Having documentation not only means speedy on-boarding for new team members but also brings order by having the whole team synchronised on how release management works. This involves all parts of the team, not only DevOps but also developers and testers.
Are all microservice components versioned?
Every software component which is deployed either for testing, integration or in front of live users should be versioned and linked to the release notes. A good approach is to use semantic versioning and also include a GIT-SHA, so that the exact commit history can be linked to the running software.
Have you implemented performance metrics monitoring?
Once the software has been deployed to your environment, performance metrics provide an insight to know if the performance is aligned to your objectives. Often performance metrics can be a clue to design issues which only become obvious under particular situations such as user traffic, end devices and timing. Not having this information can cost time, resources and diminish the user experience of the product.
Do you run automatic tests as part of the build/deploy process?
Having a strict criteria for every deployable component should be documented and implemented as automatic test. These tests allow DevOps to catch buggy/faulty software before reaching the users. Another benefit is also continuous improvement in quality by the extension of tests covering newly discovered issues.
Do you have automatic vulnerability scanning?
Security must be taken extremely seriously and automatic vulnerability scanning is just one aspect of security. Tools like Anchore enable you to scan docker images against a public database of known vulnerabilities, which is regularly updated. However, don’t assume that passing these is a sufficiently high bar of security. This should be a major consideration for every segment of the project. You get to a point where more automated scanning will not help you, instead you would need work with your developers to set out and abide by a set of standards, so all code is uniform and secure. This should not only cover the code but also the infrastructure.
A few things to consider
- Role Base Access Contol for Infrastruture and Source control
- Use popular/well maintained packages in your code
- Use popular/well maintained base container images
- Adhere to a set of API standards such as Zalando RESTful API and Event Guidelines
- Restrict network access between microservices
Do you have fully automated Infrastructure as Code?
Infrastructure as Code (IaC) isn’t a new trend in DevOps, but a well-established and very practical one. Some of the benefits are the ability to orchestrate environments quickly and in a highly structured and repeatable manner. Good practice is to have your infrastructure code committed in Git. Some useful tools to implement this are Ansible, Chef, Puppet, Terraform.
Do you have a bug database?
Having a system to manage bugs and issues is a good practice which enables the efficient management of bugs in your software. It provides a level of visibility and helps identify areas where more work is needed.
Do you write tests for all newly found bugs?
One other benefit of having a bug database is that you can connect it with automatic tests which cover know bugs in the future. This will prevent a bug reappearing again in the future once it is caught and fixed.
Do you have meaningful logs?
Having a good log management is absolutely essential to DevOps and system quality. Not having enough logs or insufficient quality of logs can mean being unable to fix an issue. There are several aspects in logging which must be implemented.
- Centralised logging – collect log information from all running components in a centralised system.
- Having enough detail resolution – the ability to collect all necessarily parameters like user, environment, date and time, version, input/output.
- Meaningful information – Having logs is great, however having logs that are meaningful is even better as it provides you with the right information to work out why something isn’t working.
- A good logging strategy enables developers to reproduce issues with close to 100% realistic conditions on a local dev environment and diagnose and fix the issue.
Do you have system and data recovery strategy?
Doing backups is just not enough. You should plan for recovery which includes backup, orchestration and installation. Your recovery strategy should account for the environment, application and user & state data. Ideally you should be able to bring up the whole infrastructure automatically if it is destroyed.
Do you have separate development, test, test, test, integration and production environments?
A good DevOps teams always have distinct environments for development, testing, integration and production. Those environments should ideally be identical and software flow between them should be managed by a system. For example, untested software should never be installed on production.
By Will Dewhurst, DevOps Engineer at ANS.
If you want to learn more about how to improve your DevOps capabilities, take a look at our DevOps services here.
