Skip to main content
IBM Developer
Sign In | Register dW
UrbanCode
  • Products & Solutions
    • UrbanCode Deploy
    • UrbanCode Velocity
    • UrbanCode Release
    • UrbanCode Build
  • Plugins
  • Docs
  • Videos
  • Forum
  • Blog
  • Events

Yearly Archives: 2018

UrbanCode Velocity strengthens VSM position

ICPOpenShiftVSM
Tom Hudson / December 15, 2018 / 0 comments

UrbanCode Velocity is introducing new features at an accelerating rate. (Insert your velocity-related pun here.) The 1.1.0 version introduces support for Red Hat’s OpenShift, and IBM Cloud Private. UrbanCode Velocity runs in Docker containers and can run virtually anywhere the container orchestrators Docker Compose, and Kubernetes can run; bare-metal servers, VMs, public or private clouds—you name it.

Since its initial release, UrbanCode Velocity has provided strong Value Stream Management (VSM) features. Using the Pipeline, you can integrate popular tools, such as UrbanCode Deploy, Jira, Jenkins, and ServiceNow with Velocity’s own lightweight release management and reporting features.

VSM

VSM comes out of lean manufacturing where customer value drives the manufacturing process. With VSM, lean practices move into software product development. Because customer value already defines the Agile, DevOps software space, VSM is a compelling fit.

It’s hard to define VSM in a simple blog post without sounding like marketing gobbledygook. This definition is OK although vague: A value stream represents the steps that an organization performs to provide continuous value to customers.

The challenge for agile software developers is that the value stream is difficult to measure. Automated tools are frequently silo’d and handoffs between tools and organization are too often ad hoc or otherwise hard to trace.

The truth is that no one tool in the IT toolchain contains all the critical information required to deliver an effective or reliable value stream. Information is strewn across the value stream in multiple systems. UrbanCode Velocity brings the pieces together in a single measurable frame. This enables a seamless and auditable transfer of information across the enterprise.

To circle back to our VSM definition, VSM recognizes the reality of multi-tool toolchains and provides the metrics necessary to ensure that development aligns customer satisfaction with strategic objectives.

It’s not just about how fast you can deliver; it’s about the value you deliver at speed.

UrbanCode Velocity is available in two versions. The free to use Community Edition provides reporting tools that you can integrate with other tools, such as UrbanCode Deploy. The full-featured Standard Edition is free to use for 60 days.

New Safe Edit functionality in Deploy V7

Process DesignerSafe EditUrbanCode Deploy
TracyGavlak / December 5, 2018 / 0 comments

Safely test process changes in your production UrbanCode Deploy environment with Safe Edit. This allows you and your team to bypass any long promotion processes, which can take weeks to complete. This is ideal when you need to make a change quickly and can’t afford the time it takes to complete a full-testing cycle.

There’s an optional feature within Safe Edit to require manual approval before a new process can be used in a production deployment. This allows process changes to be reviewed and tracked before they are promoted.

Drafts can be locked as well, preventing teammates from stepping on each other’s changes. Locking a process provides visibility to others by letting them know a change is in process.

Safe Edit is a real time saver while providing visibility and tracking into process design.

Learn how to work on processes in safe edit mode here.

Check out the Safe Edit overview video here!.

Web Agents Bring Greater Scalability and Stability to UrbanCode Deploy

performancescalability
Brad Springer / November 25, 2018 / 0 comments

With the release of UrbanCode Deploy 7.0 customers have the option to use Web agents instead of JMS agents. Web agents which are based on websockets, offer many advantages and are the future of UrbanCode Deploy. In our lab we conducted testing which shows significant improvements in stability, scalability and performance. Below is a summary of the results of that testing.

Stability
Our destructive testing included the injection of random potential failure events (PFE’s) into a UCD environment. Examples of PFEs include severed network connections, relay restarts and server restarts. An actual failure is defined as the inability of UCD to reach a stable state within a 20-minute period after experiencing a PFE. Our tests compared JMS agents with Web Agents in topologies consisting of 25,000, 50,000 and 100,000 agents. With JMS agents enabled, UCD was barely able to come online with 25,000 agents and injection of PFE’s resulted in immediate failures. With Web agents enabled test runs lasted for a 48 hour period and UCD endured thousands of PFE’s without a single failure regardless of the number of agents within the topology (25K,50K,100K)

Performance and Scalability
In order to test performance and scalability we compared JMS agents with Web agents in systems under moderate and heavy load. Moderate load testing included 600 component deployments per hour. We saw no significant difference between JMS and Web agents with the average component deployment time being approximately a minute in both cases. When we increased load to 12,000 component deployments per hour the results were drastically different. With JMS agents enabled the average component deployment time was about 100 minutes. Web agents however, maintained a one minute average component deployment time significantly outperforming JMS agents.

One other area in which we saw significant performance gains is within agent time to connect which is basically the time it takes all agents to connect to UCD after server reboot. With JMS agents enabled in a topology consisting of 25,000 agents, agent time to connect was about an hour. UCD was unable to reach a stable state at all in topologies with larger numbers of agents. For Web agents, we used a 40,000-agent topology and the agent time to connect was only 75 seconds. For customers that are sensitive to downtime during upgrades, this is a substantial improvement.

Conclusion
The results of our testing show that UCD with web agents is not only more stable and resilient, but it also performs better under heavy load and at scale. This is extremely important to customers for whom high availability, scalability and performance are important and we recommend that you choose a version of UCD that offers web agents when you are planning your next upgrade.

Security Requirements for IBM z/OS Agents

IBM UrbanCode DeploySecurityz/OS
dularkaren / November 16, 2018 / 0 comments

In-depth discussions for all information related to z/OS security can be found in these topics in the Knowlede Center:

z/OS Security

Streamlined Search for z/OS Inventory

z/OS
dularkaren / November 16, 2018 / 0 comments

The unique architecture of z/OS and its multi-tenancy partitioning posed challenges for identifying files deployed across z/OS versions for any UrbanCode Deploy environment. This challenge is addressed with the new Search feature for z/OS environments available in an upcoming release.

The Search feature is available in the user interface of any z/OS application environment. Search can be performed for any component file in the environment. The search leverages a powerful database query and sort capabilities across the environment, made possible by UrbanCode Deploy’s inherent z/OS version tracking.

Search results are presented as unique inventory entries, starting with the most recently deployed version of the file in that environment. Search results include:

• The filename
• When the file was deployed
• What version the file was deployed in
• What component that version belongs to

Inventories are searched in reverse chronological order for the file. By default, the first 1000 inventory entries where the file is first identified are returned.

The simplified user-interface provides an option to return additional entries, in order of most recently deployed.

UrbanCode Hosts Successful TechConnect Event in Cleveland Lab

BrianMuskoff / November 9, 2018 / 2 comments

The UrbanCode product team recently launched a new program called TechConnect, which is a forum to bring customers, product managers and technical leaders together. The first face-to-face event was hosted in our Cleveland lab with over 20 customers joining us for a full day of sharing best practices, providing product roadmap feedback and generally having some fun.

The event kicked off with a discussion around the current state of DevOps, where the market is heading and where our customers recommend we focus our energy. The remainder of the morning was focused on UrbanCode product roadmaps, highlighting recent deliverables and key futures. The entire Cleveland engineering team joined group for lunch and several customers shared their implementation stories including best practices, significant challenges and business results. In the afternoon, the team split into breakout sessions to deep dive into specific feature design topics.

Customer feedback from event was very positive, in fact Tom Gould from L.L. Bean shared – “This was a great event. I have never had a vendor be so open to feedback. I truly believe the time spent at this event will result in an even better UrbanCode Deploy and Velocity.”

The plan is to continue the momentum from this inaugural event by targeting similar meetups on a quarterly basis around different geographies. If you are interested in participating in the next TechConnect, please reach out to our Customer Advocacy Manager, Randi Anderson at randi.anderson@hcl.com.

Parameter Passing Across Processes

IBM UrbanCode Deploy
Eric Minick / November 5, 2018 / 0 comments

Mark Roberts takes a great look at how to capture information from one step in UrbanCode Deploy and then use it elsewhere.

Find the original post on LinkedIn here.

Introducing smart compare for the WAS Configure plug-in

Matthew Alexander of HCL / October 30, 2018 / 0 comments

The comparison feature of the WAS Configure plug-in is great at detecting differences to your WAS configuration, but what if there are differences in your configuration you wish to ignore? For example, what if there are environment specific properties that differ across environments, and you rather not have those properties flagged as differences when your WAS comparison process runs?

Starting with version 80 of the WAS Configure plug-in, we now offer the ability to ignore specific Property objects during comparison. We also added the ability to ignore specific attributes for any object type during comparison.

Check out the videos below for more information:

Managing Containers in Helm Charts with UrbanCode Deploy

Matthew_Alexander_HCL / July 17, 2018 / 0 comments

<< Back to Getting Started with IBM UrbanCode Deploy and Containers

Introduction

With the Kubernetes plug-in for UrbanCode Deploy, users may change the tag (version) of containers used in a deployment without editing YAML files. UrbanCode Deploy tracks and displays which container image versions are deployed where and when, providing auditing and ease of use.

The Kubernetes plug-in now features similar functionality for deployments using Helm charts. The container images used in Helm charts may be managed as components inside UrbanCode Deploy, eliminating the need for users to update Helm charts or values.yaml files in order to change which container version is deployed in environments.

The Create Image Components From Helm Release Step

Easily create container image components with the The Create Image Components from Helm Release step. Users provide a Helm release name. When run, the step will examine the Helm release, find all container images used by the release, then create UrbanCode Deploy components to mange those container images. The Docker Registry source configuration plug-in may then connect to your Docker registry and discover all available image tags, adding them to the component as versions.

In this example, I’ve created a generic process which contains only the Create Image Components from Helm Release step. I’ve provided my Helm release name mra-derby. Once executed, the process created a component for the container image used in my release and added a kubernetes.image tag to the component. I updated the configuration settings for my component so the Docker Registry plug-in could then connected to my Docker Registry (in this case, Artifactory). I then imported versions for the component. The Docker Registry plug-in connected to Artifactory, discovered the container image tags, and created them as versions in UrbanCode Deploy.

Add a Process to the Container Image Components

A process must be added to the container image component in order for these components to perform a Helm upgrade. The Helm upgrade will be used to change which version (tag) of the container image is used by the release. In my simple example, my process only uses one step (Helm Upgrade), however you may want to add steps to configure Helm for reliability.

In this example. I’m providing my Helm release (as a property), my Helm chart (as a property), and two flags. Let’s take a look at the first flag:

--set image.tag=${p:version.name}

The –set flag is used to override a value found in your charts values.yaml file. I determined that image.tag was the property to override by looking at my chart’s values.yaml file:

I saw that image.tag was the property in values.yaml I wanted to override. This value may be different for you. You may also want to use an UrbanCode Deploy property for this value for ease of use going forward (this would make the process generic and would allow you to use a component template).

Finally, ${p:version.name} means we are going to set this property to the version name of our component, which will be an image tag.

The next flag is:

--reuse-values

This tells Helm to leave all other values as is.

Setting up the Application in UrbanCode Deploy

In UrbanCode Deploy, create an application. Add the component that represents your Helm chart and the container image components to the application.

Build an application process.

Above is an example of an application process. The first step installs the Helm chart component. My component process for the Helm chart component downloads the chart from the component version artifact into a specific directory. The process then checks to see if the Helm release already exists. If the release does not exist, the chart is installed. If the release does exist, an upgrade is performed. See this page for an example process.

Next, my process installs the container image component. In my example, I only have one container image, so I install it directly. If you have multiple container image components, you may use the Install Multiple Components step to install all components with the kubernetes.image tag, for example. This step runs the process we created earlier for the container image component. The end result is a helm upgrade command is run to ensure the Helm release uses the image tag specified in the UrbanCode Deploy user interface.

Conclusion

UrbanCode Deploy is now setup to allow users to change which tag (version) of their container image is used in a Helm deployment without requiring the user to update YAML files or manually run Helm commands.

In the example above, version 2.0.0 of my Helm chart is deployed. The release includes a container named ucds, and the tag for that container image is 7.0.0.0.981343c-x86_64. If I want to change the tag of the container image used in my release, I could simply run another deployment, choosing which image tag to use in the UrbanCode Deploy user interface.

Good luck with your Helm deployments!

Now is the time to share your DevOps story!

ARAConferencesDevOpsIBM eventThinkUrbanCode
AlWagner / July 4, 2018 / 0 comments

IBM Think 2019 call for papers is now open!

https://www.ibm.com/events/think/call-for-speakers/

With IBM Think now accepting abstracts from people wishing to share their stories at IBM’s premiere conference, I thought I would share some “tips” & “tricks” on how best to get your story accepted. Following these ideas is not a guarantee that your submission will be accepted but it will certainly increase your chances.

Submitting a well-crafted abstract

Call for papers submission applications typically have char/word counters on several fields where you are expected to share your idea. Don’t waste that valuable space using meaningless words or phrases. Opening an abstract proposal with “Attend this session to …” just used up 22 characters or 4 words! My advice is to be concise, be clear, be clean, be complete – avoid repetition, extraneous jargon, and excessive buzz words. If you use an acronym, spell it out the first time. Don’t leave people playing the “alphabet soup” game trying to figure out what the acronym means. And finally, please please please…. proof read your submission. Bad grammar and misspellings make an abstract hard to read and creates additional editing work for the selection committee. Don’t make rejecting your submission easy for them.

Structuring your abstract submission

Having read many thousands of “Call for Paper” submissions, people often spend too much time writing what I will term as “the fluff”. This “fluff” often leaves the selection committee wondering when the abstract writer will be getting to the point or if there is a point to be made. In my opinion, a well-structured abstract should clearly speak to these 3 questions (at a high level):

  1. What was the specific problem/challenge you faced?
  2. How did you solve it?
  3. What measured “actual” business results did you achieve?

As some examples:

  • Increased deployment frequency by 40% or even better, improved release capabilities from 3 months to 1 month
  • Increased deployment success by 80%
  • Reduce mean time to recovery by 25%
  • Reduced testing cycle from 2 months to 1 week

Lastly, the abstract should close with a commitment on the 2 or 3 things you promise to deliver during your session and what the attendee will leave with.

Be prepared to deliver on commitments made in your abstract

Too often, there is disconnect between the submitted abstract and presentation delivered. The result is often a dissatisfied audience leading to poor session rating, poor Speaker rating or both. In some situations, the selection committee may look at past results and previous Speaker ratings to provide insight on who will deliver the best content. My best advice is to follow Stephen Covey’s guidance and “begin with the end in mind”. The details of your abstract are your commitment to the audience. The more concise your abstract is, the easier it is to build the presentation and meet the expectations of the attendees. Happy attendees translate into higher sessions ratings and Speaker ratings.

So, let’s think positive for a moment. You have just received your acceptance notification. Next step is to build that demo asset, workshop curriculum, or presentation. What details will you include in the session material?

My suggestion; quickly build the session outline as a straw-man using bullet points:

  • Present the problem and explain the solution – in detail! I have walked out of many sessions where the problem was clearly stated, the Speaker said they fixed it sharing how smart they were but offered no insight on how the problem was resolved. I wanted details!
  • Share assets that helped solve the problem. If you write a utility or code snippet that could add value to others, share how you went about developing the utility or share the code with the audience.
  • Proudly display your tool chain no matter how simple or complex. In fact, tool chain slides often get the most photos taken. HINT: Be sure to stand close to the screen, be part of the picture and enjoy new found social media fame! For some reason, people love to tweet pictures of others’ tool chains!
  • Talk about what worked, what didn’t, experiments performed, and lessons learned. DevOps is about continuously learning, experimentation, and failing safely. Be fearless in sharing. Your experience and expertise can save others time and garner respect for yourself with peers.
  • Introduce what you may do next to become even more effective. DevOps is a journey. Having that longer-term vision and sharing that vision with others may spark a new collaborative relationship with someone who has a common interest in finding the solution.
  • Present concrete measured (qualified and quantitative) results – tied to the business. DevOps is about delivering results to the business. Sharing your results can help others see the possible and the potential outcomes.

Now that you can envision what the end looks like, work backwards and write the beginning – the abstract you are going to submit.

Remember people are coming to learn from your experiences – you are the teacher. And like Teachers, Speakers have a responsibility to connect with each attendee and work to share a piece of knowledge with everyone in the room. This is your chance to shine and share your expertise with others.

IBM Think 2019 DevOps stories we are looking for but are not limited to…

  • Continuous delivery and continuous testing on the mainframe
  • Increasing DevOps maturity: Value Stream Management
  • Deploying containerized applications with UrbanCode Deploy
  • Solving the DevOps “Day two” problem
  • Cultural transformation to achieve desired business outcomes
  • Deploying hybrid applications in hybrid environments
  • Virtualizing containers and other software dependencies for the purpose of testing

And be creative! Session delivery doesn’t need to be “death by slide ware”. I encourage those submitting abstracts to think about how they might get “outside of the box” delivering their story in a new and fresh innovative way.

IBM Think 2019 Call for Papers closes July 16, 2018.

https://www.ibm.com/events/think/call-for-speakers/
Why wait? Submit your ideas today. And good luck!

Thanks for reading
Al

Al Wagner is an IBM technical evangelist with more than twenty years of practical field experience in development roles driving thought leadership, strategic initiatives, and tangible solutions around DevOps and continuous delivery. Focusing mainly on deployment automation and continuous testing, Al has practical knowledge of the IBM DevOps solution having assisted, mentored, and enabled both internal IBM and external customer teams to solve their IT challenges. He has spoken at numerous conferences around the world on software development –principles & techniques – and authored/co-authored numerous papers and books including Application Release and Deployment For Dummies, Continuous Testing For Dummies, and Service Virtualization For Dummies.
Next Page »
Date
November 2019 (1)
October 2019 (1)
September 2019 (5)
August 2019 (2)
July 2019 (1)
June 2019 (6)
May 2019 (7)
April 2019 (7)
March 2019 (8)
February 2019 (3)
January 2019 (2)
December 2018 (2)
Tags
Follow us on Twitter RSS Feed
  • Home
  • Products & Solutions
  • Docs
  • Videos
  • Forum
  • Blog
  • Events
  • Careers
  • Report Abuse
  • Terms of Use
  • Third Party Notice
  • IBM Privacy
IBM