1. Top of the list was the reception that the Dimensions CM preview received. You can sign up for the preview program here. The reaction from customers was amazing. They can’t wait to get their hands on the finished version.
2. The DevOps Panel (photo above) featuring Eric Kunkel (MMA), Damon Edwards (DTO Solutions), Dave West (Tasktop), Greg Sikes (Serena) was extremely popular.
Observations were spot on and the banter was extremely entertaining. Watch the xChange13 DevOps Panel and see for yourself!
3. A hot customer session was Ron Rogeau of UBS presenting how Serena Release Manager is being used at UBS to transform release management. The room was packed and there were a lot of extremely interested people eager to learn about Release Management at enterprise scale.
4. Serena CEO Greg Hughes presented the top 5 priorities to transform your release management and elevate your career which really got attendees thinking about release management possibilities.
5. As it was my first xChange conference I was particularly impressed at the passion of the attendees. Many have attended xChange for several years and still turn out with enthusiasm. Their trips are made worthwhile with the assurance of learning something new and having great conversations.
I’m looking forward to the next xChange and other customer events around the world. See more photos from xChange13!
Day two at xChange picked up where day one left off with more excellent, informative and entertaining sessions. I spent most of my day in the Industry Trends & Hot Topics track. The track started with Damon Edwards giving some practical tips on getting started with DevOps in the enterprise.
I delivered a session on building your own DevOps tool chain. The goal of the session was to initiate discussion about what has been tried when building tool chains, what mix of home grown, open source and commercial software has been successful. There was a lot of interesting discussion with lots of grimaces and knowing smiles when I described my experience of moving from homegrown solutions to a commercial/open source tool chain. They, like me had been burned by the success of their home grown solutions so using commercial and open source tool chains was preferable.
I heard rave reviews of Dimensions 14, the new version of Dimensions CM scheduled for release next year. We have been demoing it at xChange and people are extremely impressed.
The day wrapped up with a great party with salsa dancing and lots of great discussions.
I suspect there may be a few headaches on Wednesday morning as people were having a great time.
I’m really looking forward to Wednesday. In case you missed them, you can watch video recordings of all the general sessions at http://ser.so/x13videos.
We are proud to announce the latest update to Serena Release Automation (SRA). Advancements have been made in several key areas:
You can read the press release for an overview of all of the new features in SRA (screenshot above). Here are three areas I am particularly excited about.
Ease of use
Ease of use is an area where application release automation solutions have been too complex. In this release, we have embarked on a UI refresh, starting with a task-based UI. The menu structure has been simplified and the UI doesn’t lose context when switching between tasks, which can be a significant time saver. There are also quick links to recently used application pages. The end result is a significant decrease in the ramp-up time for new SRA users.
A differentiator in the world of Application Release Automation (ARA) is High Availability (HA). While HA has been common in other areas such as database servers, high availability has been lacking in ARA solutions, primarily because existing solutions have been focused on team level use cases. When embarking on an enterprise-wide application release automation initiative, availability of the SRA server is critical. Failure no longer affects deployments at a team level. If the application release automation server goes down in the enterprise, multiple complex deployments could be impacted.
With SRA the automation server can be configured in a cluster. This not only ensures that the server is always available but also that servers are hot swappable, which allows for in-place upgrades, further reducing downtime.
We aligned security privileges with enterprise-class security standards. In contrast, competing ARA products require the use of elevated security privileges, like being required to run as root. Enterprise adoption will be even easier than before since security exceptions don’t have to be granted anymore.
Sign up for our September DevOps Drive-In webcast to learn about implementing continuous delivery with Serena Release Manager and to see Serena Release Manager and Serena Release Automation in action.
Day one of xChange13 has come to an end and what an awesome day it was. The highlight of my day was the afternoon general session speakers. Damon Edwards presented a fantastic session on The DevOps Advantage. Unlike most DevOps sessions I have seen in the past, this session hit the bullseye for explaining the benefits of DevOps in the enterprise. Looking around the room there were many people taking notes and I know Damon had some great conversations with people later in the day.
After Damon’s presentation the room was enthusiastically waiting for the DevOps panel discussion. We had some excellent experts on the panel:
The panel was lively, with good chemistry between the panelists. The only major point of contention was DevOps vs. NoOps, which started a great discussion on what NoOps really is. The point was successfully argued that NoOps doesn’t mean not having Ops skills in an organization. It isn’t realistic for Dev to take over the role of Ops people, and companies that have tried generally fail quickly. The benefit of failing quickly is being able to course correct quickly and then something close to NoOps begins to happen.
If you want to use the term NoOps, then I think it really means that there isn’t a separate Ops team. Teams are truly cross functional, containing both Dev and Ops expertise. Amusing banter around DevOps, OpsDev, BusOpsDev ensued and further reinforced many points Damon made in his presentation.
On day two, both Damon and Dave are presenting breakout sessions and I, like many others, can’t wait to hear what else they have to say.
Finally, a big thank you to everyone who presented sessions today, I think it is safe to say that everyone learned something new and had a fun time doing so.
Watch the video of the DevOps panel discussion on YouTube. Also, check out the xChange13 playlist. All videos from the user conference will be posted there.
Our global user conference, xChange13, is about a week away and we’re all extremely excited and busy making sure that attendees have an amazing show. I’m primarily focused on the Industry Trends and Hot Topics track and we have some great content.
We are fortunate to have Damon Edwards of DTO Solutions presenting a keynote and breakout session. Any lingering doubts you may have about DevOps being a fit in the traditional enterprise should be laid to rest after attending Damon’s sessions. Damon will educate you on value stream mapping, timeline analysis and waste analysis, which will help you navigate your way through complex enterprise DevOps initiatives.
At xChange13 we’ll also discuss how to use Serena’s solutions with other commercial and open source software to build DevOps tool-chains that work in your environment, making use of existing investments you have made.
In addition to DevOps and release management content, many other topics will be covered. Head on over to the xChange13 website and take a look at the agenda. There’s still time to register. If you are going to xChange13, I look forward to talking to you about DevOps and release management and hearing your wonderful tales of challenges, successes and future dreams.
See you there!
As I wrote in my previous blog post, “Using Serena Release Automation and Infrastructure as Code to Build Your DevOps Solution,” Puppet can play an important part when used in conjunction with Serena solutions.
Plenty of enterprise customers were in attendance and there was a great session on Puppet Enterprise at Scale by Benjamin Irizarry of Bank of America, which is a good example of how infrastructure as code initiatives are no longer confined to start-ups.
DevOps and Continuous Delivery were hot topics, with an excellent session by Eric Shamow of Puppet Labs on Continuous Delivery. View the presentation.
The one thing that stood out at PuppetConf is that process orchestration is still a big problem, as illustrated in Eric’s demo. Using Jenkins plus plugins makes for a simple demo for Continuous Delivery but it doesn’t change the fact that CI tools are build-centric and there is much more to a release than the output of a build. Eric did not suggest that using Jenkins to drive a continuous delivery pipeline was good for production, just that it made for an easy demo.
The lack of a good orchestration framework is something that we frequently hear from prospects and customers with release management problems. Serena Release Control is a key piece of a modern release management solution, providing auditability, visibility and control of a release process, and integrating with commonly used tools in both the Dev and Ops space. This visibility and auditability is possible because in Serena Release Control everything flowing through the system isn’t a build. We orchestrate releases, capturing all of the data that is associated with a release and reporting on it in the context of a release. CI tools form a critical part of a release management process; they just aren’t a good choice for orchestrating your release process. See how Serena Release Control works within our release management solution.
I recently read a fantastic article by Jens Segers on infrastructure as code. I’m already a big believer in infrastructure as code and agree with Jens that it doesn’t matter which tool you use as long as you strive to have an infrastructure as code initiative.
That leads to an interesting question. Where do infrastructure as code tools such as Puppet or Chef fit into the picture if you are using Serena Release Automation (SRA)? To me these tools are great for operating system configuration and generic stack provisioning, which just happens to fit in perfectly with SRA. I see infrastructure as code being used as part of an SRA process as follows:
By using SRA and Puppet/Chef in this way, each tool is playing to its strength, allowing for an effective deployment automation solution both when designing and maintaining the solution and at runtime.
Last week I had the pleasure of working in the Serena booth at Agile2013 (me and a Shania Twain look-alike in picture to the right). While there were quite a few booths, some very creative, it was a fairly low energy expo area. That doesn’t mean we didn’t have some great conversations.
Agile2013 had a DevOps track. There were plenty of people who stopped by our booth who wanted to learn more about DevOps. They were from many different industries, which is what I would expect.
The general consensus seemed to be that while agile methodologies had resulted in significant benefits to organizations, there is still more work to be done and DevOps has a key part to play in the evolution of agile development shops.
People were especially interested in how Serena solutions can track release content and automate application deployments. They were keen to use their existing solutions, which works well for Serena as we have a policy of coexistence. You can read more about mixing commercial and open source software in my recent blog post.
Finally, our partnership with Tasktop also generated some buzz. In the coming months, Serena customers will see some awesome benefits from the partnership as we expand our integration capabilities further.
I’d like to say a big thank you to all who stopped by the booth. We are excited to present Serena’s latest innovations to you over the next few months. Stay tuned for upcoming webcasts to learn more.
I’m going to open with a fact that should hopefully be obvious: Few organizations have a completely manual software release process.
I can imagine you saying things like “Duh! So what? What’s your point?”
The fact that partial solutions to software release problems are already in place poses an interesting problem for software vendors. Some vendors pursue a policy of attempting to replace existing tools with their own products. Others, including Serena, believe in co-existing with and adding value to solutions they have already invested time and effort in using.
A strategy of co-existence between commercial software vendors is not new. A problem often presents itself culturally when open source enters the equation. Those of us that use open source solutions tend to be rather passionate about them, and I count myself amongst those people. The cultural problem that presents itself is that some people are “open source purists.” In this sort of situation there is a heavy bias to using a combination of open source and homegrown software. While this is great in theory, the fact is that there are only a relatively small number of companies that have the combination of the right number of staff and the right skillset to pull this off.
For most organizations complementing open source and homegrown software with commercial solutions makes sense, but when and how?
In the enterprise, the flow of information can be extremely complex. Gathering this information, presenting a unified view of the information and using it to influence behavior in a workflow is a difficult task. For example, human and computer processes need to be modeled and many systems need to be integrated.
A holistic, process-based approach, handling the flow of information between systems using integrations, is an area where commercial software can add significant value on top of open source and homegrown solutions.
So how do you get started, what should you look for in a vendor when mixing open source and commercial software?
When selecting open source solutions to co–exist with other solutions:
I’ll continue to blog about this topic and others related to DevOps. So I encourage you to subscribe to the Serena Blog and catch all upcoming posts.
DevOpsDays Silicon Valley was the biggest DevOpsDays event yet. The event had a more professional feel than previous events I have attended. This is not to say the other events were unprofessional, just that the layout and facilities were in a more traditional conference setting.
Attendees from “enterprise” companies were out in force to learn more about DevOps and there was an excellent open space session about DevOps in the enterprise, which was well attended.
The one session that really stood out was Jeff Sussna’s (@jeffsussna) session on Continuous Quality, which was fantastic. Over the past few years, great advances have been made in the Dev and Ops spaces but QA has been somewhat overlooked. The shift in focus from Quality Assurance (which frequently means validation of fixes) to Quality Engineering sets the stage for Continuous Quality.
I agree with Jeff that QA engineers are customer advocates and should be brought into the design process as early as possible. However, as always, keep in mind that the way someone is measured influences behavior. I have witnessed people trying to influence a design so that it is easier to test, not easier to use. Fortunately, the move from Quality Assurance to Quality Engineering will result in the focus changing from simply verifying that a fix has been done to really being an evangelist for the end user.
This leads me to something that is key to success in a DevOps initiative. Incentives must be aligned. If QA is measured by the amount of defects that have been verified as fixed then they will prioritize that first. The same if Dev is tasked with making changes and Ops is tasked with ensuring stability; each will focus on meeting their own goals, which will frequently conflict. By ensuring that goals are aligned with business outcomes and are shared across teams, conflict will be reduced and Dev, QA and Ops can all focus on delivering quality products to customers faster.