Software development reset – A remote DevOps epiphany

No aspect of society seems able to escape being altered by the tragic outbreak of COVID-19. The now well-known slogan “Stay-at-Home” has given rise to a future where working from home has become the norm rather than the exception. Even the IT sector has felt its impact. New ways of working and collaborating are being quickly deployed and implemented. Many organizations are learning they need to re-engineer business and IT processes and how they are consumed in order to adapt.

Within many software development environments, software design, creation and testing is done on-premises; behind the corporate firewall, with operations and development working within a physical office environment. As organisations move towards adopting DevOps work practices, these principles of DevOps are being applied within the four walls of an office environment. Now, with the new reality of working from home, remote DevOps practices need to be looked at to reduce the development cycle through continuous integration and delivery.

The pandemic’s influence on DevOps

I believe, as a consequence of this dreadful crisis, the need to produce more web-enabled products and services at speed will become a priority for many more organisations. Hence, embracing DevOps processes, strategies, and a cultural ethos in the remote working environment can ultimately safeguard companies going forward by harmonizing remote agile collaboration and automation tools and practices throughout its development environment.

This end-to-end process can bring together users, developers, and IT operations through the application of continuous integration, delivery and testing processes within automation pipelines. A well-defined structure for remote work, paired with good remote tools, can ensure that development teams’ productivity remains high, speed is embraced, and the quality of code is maintained through static and dynamic code analysis tools.

What remote working means for developers

Essentially, working from home, whether you are a developer or not, means that you do not need to travel to a traditional office space and you can do your work at home. How you do it depends on your preference and your organisational culture. Some organisations may insist on some sort of oversight and may employ some sort of tracking software, so they can make sure the developer is “punching in and out” at corporate times. Working from home requires developers to have some personal traits to guarantee effectiveness, such as:

• • Initiative – Most developers I have come across don’t enjoy constant supervision, hence those that can start and work through a project on their own fare well remotely.
  • Discipline – This is often a key failing in developers, where coding is never complete as there is always a better way of doing it, improving it, etc. The willpower to resist this inclination and keep your eyes on the ball is the key to working remotely.
  • A dedicated space (not your bedroom) – Developers, like all remote workers, need a place to work in that is separate from social home activities. Such a place provides the mindset that, when you are there, you know you should be working and not procrastinating.
  • A willingness to improve communications skills – Continuous communications with colleagues, bosses, customers, etc. will ensure that developers become trusted partners despite not working in the same room together. This inevitably involves into having clear and constructive conversations with users that underpins seamless software delivery.

Remote DevOps and user stories

Most developers know user stories (epics) are used as the basis for estimating, planning, and understanding whether value is/was delivered to customers. This is a key component to an effective DevOps strategy. It breaks large tasks down into smaller chunks that deliver value independently to make the work easier to visualize and understand. The potential benefits are obvious, as meaningful segments of work can be accomplished simultaneously within an inherent customer focus.

Remote virtual work should not decrease the efficiency of good user stories (even though a physical story card is not on constant display) since digital tickets are virtually available. For instance, use a tool like Miro^© online, a collaborative whiteboard used to create virtual Post-it notes with the basic 3-C concept of card, conversation and confirmation – writing on the virtual Post-it “as a ‘user type’, I want / need ‘goal’ so that I can accomplish ‘justification/business value’ ”. (Of course, don’t forget the context of this Post-it.)

The brevity will ensure that greater emphasis is put on the conversations between the various stakeholders. It’s only once the conversation is complete that formal confirmation happens and there is mutual agreement on what will be delivered and when.

Developer virtual myths

The new normal of virtual working may pressure some developers into a quarantine-style existence and personal traits will push individual developers differently. It is therefore important to dispel any remote working folklore myths and legends that some associate with virtual working, namely:

• • Working remotely means I am isolated and on my own. To some developers, this is actually bliss (i.e. the much renowned hacker in his bedroom), as it may allow them to focus without office distractions. However, an effective developer is not an island and hence needs to collaborate continuously with his peers, customers and partners. Developers do not necessarily have to physically see people to avoid the feeling of loneliness or isolation. There are a number of virtual spaces (like Miro or Skype for example) that provide that real collaborative feeling of catching-up with colleagues.
  • As a junior member of the development team, you can’t work alone. This is so untrue that it is unbelievable that some developers feel this way. This is not an issue for junior developers, but of the organisation that hired them, as the organisation does not have the correct processes in place to support the junior developers. This can include, for example, a lack of effective feedback, inadequate on-boarding, and senior developer mentoring, to name a few.
  • Developers lose or misunderstand company culture. Office culture evolves over time. Culture can include ethics, values, integrity, principles, and reliability. The key to remote culture assimilation is to focus on how the organization uses its remote channels to convey what is expected.
  • Developers cannot build personal relationships if they don’t meet. Millennials have come to terms with the nature of friendship over social media. This should be no different for developers when working remotely. Using virtual tools to communicate can assist developers in having more direct technical conversations online when needed, as a developer is able to produce a considered response to an issue and not respond just because someone is standing in front of you.
  • Developer collaboration is reduced through working remotely. For developer teams that are not accustomed to remote work, shifting to a virtual world just requires revisiting approaches to collaboration, communication, security, quality control, individual and team performance, work assignment, compliance monitoring, and governance.

Three steps to get to remote DevOps

I suggest that the following three basic remote DevOps principles need to be considered when approaching DevOps remotely:

1. Remote teamwork is essential. Sitting down with a colleague at their desk is not possible. You will need to use remote communications tools to chat and collaborate. But, in this remote world, it is essential to explain the problem comprehensively with well-thought-out descriptions and documentation. Eye contact and body language will not be the key to understanding – documentation will be. At last, developers will be forced to document their software.Obviously, remote working provides better work-life-balance in terms of the flexibility of work and when to work in a 24hr period. However, it will mean that someone working from home cannot be an island and needs to be integrated fully into the corporate ethos and standards through effective communications and contact.  Additionally, corporate security policies need to be maintained end-2-end through effective security tools, encryption and policies. For example, through HPE’s GitHub repository, teams can securely share code safely with appropriate fine-grained access controls and effective two-factor authentication.
2. Corporate continuous integration within a remote working environment is mandatory. Developers writing code from home, like the young hackers in their bedrooms, require secure access to the corporate environment so that they can spin up a container, run their code, and start testing. Within a CI pipeline, automated services will take that code, spin up a container and run all the needed tests and standards (formats). This pipeline will provide the results back to the users in seconds, provide a repository (like HPE’s GitHub) for all code, all in an automated way.Effective CI/CD pipelines are outcomes of the DevOps world and, as such, are critical in the virtual work as well. There are many CI/CD tools (i.e. Jenkins, etc.) that can assist in this endeavour.  This brings us to integration needs which are even more fundamental in the virtual world.  To help, DevOps apps such as GitHub can be the best place for virtual working to share code with remote co-workers.  However, there will also be a need to use cloud resources within the concept of a cloud software containers across clusters. This is where Kubernetes provides building block entities within PaaS services.
3. Corporate continuous deployment within the remote working environment is also mandatory. This is so code can be automatically merged safely into the master production environment by wrapping the code in a bundle, creating a new container, and deploying it. It also ensures that IT production and system administration staff (who are also working remotely) can instantly view it and support it.Today’s new normal still requires continuous software delivery, which is demanded by the ever increasing virtual world of apps. Gone are the days when software deployment was at the behest of long-winded and time-consuming IT processes. Users demand new app releases in real-time. Virtual DevOps requires the tools, automation, and resources to deploy at will. This is where hybrid “as-a-Service” services are essential to continuous deployment, as they provide this ability.

Fundamental to these three steps for remote DevOps is the need to have an effective cloud working experience that developers can trust and use/consume. This cloud service must be designed with DevOps in mind in terms of the required performance for a development environment; in other words, a true Platform-as –a-Service (PaaS) provision.

What I mean by this is that it must go over and above the basic well-known marketing terminology of cloud services, i.e. elasticity (which we need to provision the right cloud services on request), agility (for rapid testing and experimentation environments), self-provisioning (for dynamic service utilization within an auto-scaling environment) and security (for appropriate access, firewalls, VPNs, Secure Endpoints, etc.).

Through such a cloud service, DevOps developers will get the level of redundancy needed to continue their work in today’s environment. In addition, their work will be automatically backed up and they will encounter minimal process interruptions.

Conclusion

This is just a start as to how to deploy a remote DevOps working world. You could go even further and automate many of the administration jobs by setting up measurements and metrics that will auto-manage the space and performance requirements of the containers, servers, etc., which, in turn, could lead to a NoOps nirvana.

As DevOps comes of age, it will undoubtedly be affected by this frightful crisis that makes a remote environment a mandatory condition. We have always known DevOps adoption would take time, and time has a way of introducing change. It is always been said that transitioning to DevOps is, first and foremost, a cultural shift, and then a process and organisational shift. The need for remote working has highlighted the need to work differently – with open collaboration, trust, working to an output not a time, reduction in the human touch, and many other things which have always been part of the DevOps Culture.

Get started with DevOps and your transformation today by visiting our HPE Pointnext website. And be sure to come back and check out the HPE DEV blog for more articles like this.