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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.