Tag Archive for: Configuration Management

As part of our ongoing Ask Jama webinar series, covering customer questions and best practices, our most recent webinar was all about the details of the latest product roadmap enhancements related to baselines and how these changes benefit our customers, especially when it comes to compliance.

In this webinar, a panel of Jama Connect experts discuss the top updates that have been released, and the future of baselines in Jama Connect.

This webinar was well received by our customers, and we wanted to make sure nobody missed out on this great content. Below, you’ll find a recording of the webinar and an abbreviated transcript.

Ask Jama: Defining and Implementing Baselines to Simplify Compliance

Julie Goodner: I’m really excited to show you the enhancements that we have made to the Baseline area along with giving you a sneak peek of where we’re headed. Over the last few releases, we have dramatically changed the look and feel of the Baseline area of Jama Connect. We’ve worked extensively on permissions, auditability, and usability to make Baseline workflow more efficient.  

I’ll be walking you through the way we have dramatically enhanced our Baseline preview, the list and reading views, the header activity stream and our new slide over panel preview. Everything that I’ll be showing you today has come from direct customer feedback and I’m excited to show you where we’re at and where we’re going. Over the years, we’ve received feedback from our customers regarding enhancements to the Baseline tree.  

This was a large body of work that we hope creates a more useful and consistent experience for you. You can now add all version core and custom fields to your baseline list view including the workflow status. When looking at your baseline list view, we now provide a count of all the items that are included. So, at a glance, you can easily see the scale of your baseline items.  

Watch the below recording to see the top five improvements to Baselines in Jama Connect in these key areas:

  • Baseline tree view
  • List and reading views
  • Baseline header
  • Activity streams
  • Slide-over panel previews

fd

Adrian Rolufs: Now we’re going to talk a little bit about how to utilize these baselines and the new capabilities that Julie just described in Jama Connect while you’re doing your requirements engineering work. Most of the work around baselines is focused on the management of work products.  

We’re going to talk today, about how that work aligns with your compliance needs and we’ll talk about how different standards for different industries drive those requirements. We’re going to talk about how that aids in understanding the traceability during your document life cycle and we’ll also focus on some best practices around what we find works best for our customers when managing baselines in Jama Connect.  

First of all, let’s take a look at the automotive industry. If you’re developing automotive products that have a functional safety concern, then you’re typically following ISO 26262 as part of your development and if you’re developing software, you may well be following Automotive SPICE. Both of those standards or regulations have requirements that are met by the Baseline features of Jama Connect and that falls under the categories of configuration management as well as document management.  

Those standards require that you are able to keep track of the versions of the documentation that when you have a completed product, you can point back to the specific versions of the requirements that it met and the Baseline feature of Jama Connect is the way to do that. If we switch over and take a look at the medical device industry, in the medical device industry, there’s a design history file or DHF that is required to be generated for every product that is submitted to the market. 

RELATED: An In-depth Look at Defining and Implementing Requirements Baselines

That DHF, an integral part of that if you’re using Jama Connect is the baselines, the baseline captures exactly the version of the content of each of the different work products that’s going to go into the DHF and typically, there’s a baseline for every work product and an exported document to a QMS system that goes along with that. So, similar to the needs of automotive but a little bit different terminology.  

Now, if we take a look at airborne systems. Each of the requirements or the standards that’s typically followed there has requirements for configuration management. Configuration management is typically the activity that is most closely associated with the Baseline function of Jama Connect and you’ll see there’s sections there that drive that as well. The nice thing is even though there’s different standards for different industries, they’re largely requiring teams to achieve the same goals.  

So, the common functionality provided by Jama Connect through the baselines and version history meets those requirements and that’s what we’ll be looking at today. First of all, what is that common workflow through Jama Connect that meets all those requirements? For any work product or document that you’re generating from Jama Connect, it generally needs to go through the same process.  

You’re going to create the material either by importing or creating the content in Jama Connect, you’re going to build traceability using the relationship features of Jama Connect to associate the individual requirements with other requirements or test cases. That material then needs to go through a comprehensive review process to make sure that the right people have reviewed the content for accuracy, completeness, verifiability, ability to implement a solution and capture that feedback and then eventual approval in Jama Connect.  

Once you have that, you then will have baselines that came about as part of the review process and the final baseline that was actually signed off in Jama Connect, you’ll want to capture as an official record saying that this is the signed off version that we are building our product to meet. And then finally, in many cases, it makes sense to export a document version of that to check into a PLM system or a QMS system or to distribute to other people who may not have access to your Jama Connect environment.  

You can view the full webinar by clicking on the button below, or take a moment to go back and watch a few of our other Ask Jama webinars, like this one on release management options in Jama Connect, or this one on moving from a document-based design control and risk management in medical device development.

Watch the full webinar to learn more about the latest product roadmap enhancements related to Baselines, and how to get the most out of Jama Connect.

WATCH NOW

At Jama we have migrated lots of functionally from Chef to Docker. Maybe that sounds a little odd? At first glance Chef and Docker don’t overlap much in functionality. But, as we develop our system with Docker, we constantly find ourselves referring to our Chef code for reference and as we implement new work in Docker, we find ourselves with functionality that allows us to deprecate our Chef based systems. What we’re looking at is two very different approaches to solving the same problems. We still have a lot of Chef kicking around so the rough edges of both Docker and Chef are constantly on my mind. These tools provide interesting points of comparison to each other.

Idempotency vs. Immutable servers

The configuration management tool domain specific languages (DSL’s) themselves are the most notable difference between Puppet and Chef. At times Puppet can feel painfully inflexible, while Chef makes sure to give you more than enough rope to hang yourself. Both try to push you toward good practices. Both encourage you to produce a catalog of idempotently applied declarations. At first glance, Docker seems to encourage you to throw out the best practices of configuration management tool languages; dockerfiles look suspiciously like shell scripts. Then you realize that every line of a dockerfile is creating a file-system snapshot and its clear that Docker is trying to solve some of the same configuration management challenges in a really different way. I should point out that nothing stops me from running Chef from within the Docker file but in practice I don’t know of anyone doing that.
Docker encourages you to wrap up most of your system as a reproducible and immutable image while configuration management tools encourage you to express your desired system state as a set of declarations. Both of these approaches help you avoid creating unnecessary complexity and both have weak points. With Docker I have concerns about how I will handle orchestration tasks in an emergency scenario. With configuration management tools I often find that what looked like declarative, idempotent code doesn’t actually handle edge cases like first boot or the existence or non-existence of a directory.
It feels like a step backwards to be doing configuration management using shell scripts and that’s what Docker has me doing. Things that I had solved using Chef’s declarative language start to turn into a procedural list of steps to create a desired configuration. On the other hand, it often feels like configuration management tools are taking on the impossible task of reimplementing and unifying the configuration languages of every piece of server software out there. At least when we fall back to shell scripts we naturally get back to handling configuration natively.
In the end, Docker or various configuration management tools all give us a way to approach defining our systems with code, code that gets checked into revision control systems.

The Image is the Cache

Docker effectively caches assets for us. As our Chef code gets more complicated we rely on more external artifacts. Although those artifacts are typically served by highly reliable services, as the number of them grows the odds that any one of them breaks on a given Chef run starts to be significant. We could eliminate that class of failure by hosting all of our artifacts locally, a strategy which requires complex artifact maintenance. Alternatively, we could use a caching proxy to access these artifacts. That reduces the risk that an artifact download fails but still would require us to maintain yet another highly available service. By using Docker, we are effectively caching the results of those downloads. We also move the impact of any failed downloads from deploy time to build time.
Failed downloads aren’t the only problem that we’d rather encounter at build time than at run time but tools like Chef don’t have a separate build time to take advantage of.
Running configuration management tools at deploy time is not only more fragile but also more time consuming. CM based deployments that I’ve worked on often take more than 10 minutes. AWS will usually get our AMI’s (host system images) into a running state in less than two minutes. We pay for that time and reliability advantage at deploy time with time spent and risk of fragility during the build.

Orchestration

Immutability itself has its disadvantages. Sometimes you can make a really small change on a system to solve a really big problem. The OpenSSL library on my Ubuntu system takes about 500K of disk space and installs in seconds with apt. To deploy the same with Docker requires a costly build step. And when our industry has wanted to deploy OpenSSL in the last couple of years, we’ve wanted to deploy it quickly.
Once, I worked in a place where Puppet controlled entries for the database servers through the /etc/hosts file on every host that would need to connect to them. One day we had a need to urgently update those host entries. Running puppet across our infrastructure could take a few minutes, but puppet was the system that had the information necessary to build the /etc/hosts file. On this occasion, the puppet server became overloaded by the level of parallelism that we were asking of it and stopped serving requests half way through the update. Rather than spending time recovering the puppet server we calculated new host entries with a shell script and pushed out the updates with parallel-scp. We would have liked a tool that could operate only on the /etc/hosts files but with all the information that the Puppet server had. In Docker small changes are even more expensive, as I described earlier in relation to OpenSSL.

Docker and Configuration Data

Chef’s databags leave us with key management pain. Docker’s golden path is very convenient when you’re working with Free Software but when you need to access artifacts that are restricted (when you need to use a password, for example as part of the download of an artifact referenced in your Dockerfile) it is very hard to keep that secret out of the Docker metadata for your image.
Docker encourages us to push as much of our configuration out of the image as possible. The natural place to move this configuration is environment variables; and Docker provides explicit support for this approach. But something has to set all those environment variables and Docker remains impartial about what. In our Chef managed environments, the same data comes from a global data store managed by the Chef server. Other configuration management tools provide similar features.
Docker doesn’t help us to manage such a global data store so we’ve been driven to start migrating our global configuration data into Consul, our discovery service of choice. Perhaps that’s a good thing; CM tools are a little awkward at the task while discovery tools can be very nimble.
Chef’s data bags at least address the issue of handling secret distribution, though awkwardly. Docker leaves us with the need to implement our own methods of safely distributing secrets needed at runtime.

Other Docker Advantages

Because we use Docker, we have a way to understand what produced our images. We can create a modified version of an image quickly. Once built, Docker images can be pushed out with less processing than configuration management code. So, despite their size, they don’t take longer to deploy.
Docker pushes us in the direction of immutable servers, servers that you never fiddle with by hand but only replace wholesale. Immutable servers set us up for really elegant zero-downtime deployments using the blue-green model. Blue-green deployments are the Holy Grail of DevOps, but there are many technical barriers to getting in a position to be able to use them. Without the constraints that Docker encourages, it would be a lot harder to lead an organization in the direction of blue-green deployments.

Docker in Production

Docker’s sweet spot is the development experience. People often express excitement when working with Docker for the first time; it is relatively easy to go from just starting out to having something that works. Things are a little less rosy for Docker in production. We’ve ended up building quite a bit of tooling around Docker to bridge the gap for our purposes.
We have not yet investigated Kubernetes or Docker Swarm to determine how we could use them with our system. One barrier to adapting these tools is the need to allow on-prem customers to deploy our containers in a simple way. That’s not a problem that everyone has to deal with but it affects how we can deploy Docker.
We have built a tool to share logic between the Docker builds of our different services, track dependencies and releases. It also helps work around the challenge of dealing with secrets during the build process. Another tool, that predated our use of Docker handles deploy-time configuration. It looks up context specific information in our AWS account and makes sure that the right values eventually get into place on the host system where a given Docker container will run. We also have tooling that collects boot-time information, from discovery services for example. Finally, our tooling handles clustering in AWS independent of any Docker-specific software.

End of Rumination …

Docker is a viable alternative to incumbent configuration management tools with its own advantages and disadvantages. Docker, like configuration management tools more generally, encourages certain good practices for integration and deployment of complex computing systems. The specific good practices that Docker encourages are different and perhaps a bit more radical than those encouraged by the more established configuration management tools.