Technical and Product News and Insights from Rackspace
Let’s face it. Every business unintentionally develops silos or divisions within business units, and Rackspace is no different. A grassroots foundation that needs to be agile, competitive, and innovative, might enter markets without fully integrating organizations into core Rackspace tooling. Enter the Process Engineering Group (PEG).
This post offers a small taste of Dutch history but, more importantly, an overview of how to user Azure DevOps to create a CI Pipeline for Hugo!
One of the things I love about working with Cloud is the various ways you can fit together different services to perform complex business functions in a relatively straight-forward manner.
On-demand infrastructure, with its speed, agility, efficient use of resources and lower costs drives many organizations toward cloud adoption.
When used in conjunction with tools like CloudFormation or Terraform, users are able to provision and remove cloud infrastructure programmatically. This is typically referred to as Infrastructure as Code, or IaC, and is great for stateless resources.
However, what if some servers cannot be regularly re-provisioned from scratch? Does it mean they need to be up and running 24/7, even if only used during limited hours?
Terraform has gained a lot of popularity in the last couple years. Rackspace
prefers to use Terraform to quickly spin up new architecture in AWS and Azure.
However, with Amazon’s lightning-fast deployment of new features, it has become
harder for the Provider maintainers to keep up. Developers are left waiting for
new features to be developed and merged into the
master branch before becoming
available for general consumption.
In Rackspace’s VMware Practice Area, we value the quality of our products very much, and we believe that quality is a team effort. The Quality Engineering (QE) team works with the Development team, Project Management team, Product Engineering team and DevOps team to improve the quality of developed products. Our quality standard has three key pillars: functionality, performance, and security. Our goal is to identify and fix defects as early as possible so that we can deliver secure functional products that perform well for our customers.
Our customers require us to develop software that is trustworthy and secure. Privacy also demands attention. To ignore the privacy concerns of users is to invite blocked deployments, litigation, negative media coverage, and mistrust. The Quality Engineering (QE) Security team’s goal is to minimize security- and privacy-related defects in design, code, documentation, and to detect and eliminate these defects as early as possible in the software development life cycle (SDLC). Developers who most effectively address security threats and protect privacy earn users’ loyalties and distinguish themselves from their competitors.
Ansible development is fast, and anyone using Ansible extensively has most likely come across an instance where a playbook that used to work does not work on a later Ansible version. Or, a system that wasn’t supported initially is now added and an existing role requires modification to make it work on the new system. See Molecule for Ansible role creation for more details on using and debugging Molecule. Creating a Molecule scenario to test an existing role allows for easy testing and modification of that role with all the benefits that Molecule provides.
In our Quality Engineering organization, we create, configure, and destroy a lot of servers via automation. Ansible is a great method for handling the configuration of servers, but the creation of Ansible roles and playbooks can be trial and error for even experienced Operations Engineers. Molecule provides a way to speed up the development and confidence of Ansible roles and playbooks by wrapping a virtualization driver with tools for testing and linting.