One of the most commonly asked questions these days is “Should all our source code be in one repository?” This is a complex question and leads to a somewhat interesting set of answers.
Before we get to that lets try and understand the question a little more and find out why customers asking this? In IT we like to centralize and optimize. Gathering all the code in one place is seen as the next logical set of distributed data ripe for centralization and optimization. All in one place means we can manage access better, manage backup and recovery better and ensure everyone is able to maximize the reuse of code.
However this flies in the face of modern developer behavior. At large and small IT organizations we see developers downloading open source source-code management systems for themselves and their teams. Instead of having one repository in one place we are seeing repositories on every server and developer hard drive creating a vast digital archipelago of repositories where processes and standards evolve on a team by team basis mimicking the finches on Galapagos recorded by Darwin.
And this is the dilemma. Corporate responsibility drives towards a single repository strategy but developer behavior wants local control and ownership of their code.
So what does corporate really want when they say they want a single repository? Typically they are trying to address multiple concerns and typically these are they:
None of these are architectural in nature: they are all functional requirements that are easy to satisfy with a single repository and very difficult, impossible in some cases, to achieve with team-based repositories.
Developers want the least amount of technology and process in order for them to develop at speed. To, as Mark Zuckerberg described it, “move fast and break things.” This means:
Once again, these requirements are not architectural. They too are just a list of requirements. While they seem in conflict with what corporate governance demands there is common ground and a proper technical solution that meets both sets of requirements is possible.
Developers fear having their code hosted on a platform that they are not developing for. Mainframe developers would never countenance their COBOL code hosted on Windows, no Unix developer would accept their code hosted there either. Developers in Beijing find it hard to accept their code hosted in Bulgaria and managed from Boston. Add to this the numerous code pages and, perhaps, ASCII to EBCDIC conversion issues that would ensue.
Most developers these days use code analysis tools designed for the development platform they are using so this means keeping the code on that platform and that in turn means duplicating the code from the single repository back to the distributed platforms.
As I said at the beginning this question raises many interesting issues. None is more pressing than this though.
Neither of these positions, single repository versus multiple distributed repositories, takes into account is that the source code repository represents the collected intellectual property of the corporation. It is a business’ most valuable asset, far beyond the goods and services they provide, and this is why it has become the single target and focus of hostile foreign governments, unscrupulous competitors, disgruntled employees and organized crime.
In tomorrow’s repository the design needs to represent best practices in secure data management. Protection of the repository is of utmost importance. This means that our repository must have:
What makes the ideal repository architecture is neither single nor multiple repositories.
Here are the key ingredients and, as you will see, they satisfy all the corporate and all the developer needs:
We call this a Single Virtual Repository.
From a management and administration point of view it appears as a single repository but, behind the scenes, the SCCM software manages all the artifacts in their respective locations on their respective platforms.
From a developer’s point of view their code is collocated with the team allowing for the fastest possible access. It also means that code analysis tools are able to execute on the code natively without duplicating the code. Each team can have their own, or a mandated process, as processes and access rules can be defined at a project or even an artifact level.
Central control but distributed data.
The world’s most advanced and successful Software Change and Configuration Management (SCCM) solutions are both from Serena.
For mainframe developers it is the legendary ChangeMan ZMF whose “develop anywhere – deploy anywhere” approach allows development on the mainframe or in Eclipse-based IDEs for deployment and execution on any of the mainframe platforms from z/OS to z/Linux to Unix System Services and Websphere Application Server.
In the distributed space the unrivaled technology is Dimensions CM which is used by the most advanced and technically savvy organizations in the world in defense, intelligence, finance, insurance, pharma and many more. Its exceptional abilities provide developers with sophisticated tools that drive development velocity and code quality.
Both ChangeMan ZMF and Dimensions CM are designed around the Single Virtual Repository giving developers and corporate governance teams exactly what they need.
And for enterprises whose development efforts extend across the mainframe/distributed divide Serena Release Control brings a Single Virtual repository across the platforms coordinating development and release activities with a single point of view and control into ChangeMan ZMF, Dimensions CM and some third party repositories.
Serena has, for more than three decades, led the field in SCCM. Those years of experience supporting the world’s most highly regulated large enterprises in their most complex development tasks give us a commanding lead in the design and implementation of source code repositories.
Don’t be fooled into seemingly inexpensive solutions that create sprawl and drag as performance slows over time. But also don’t be seduced by the seeming simplicity of one repository to “rule them all.”
A single virtual repository is the only solution that meets all the needs of developers and IT governance and Serena solutions are the only ones that offer that and that are ready today for a world driven towards the Secure SDLC.
In the next few weeks Serena is going to be announcing important new versions of our ALM, Release and Deploy solutions.
Ever since Serena’s CEO, Greg Hughes, introduced the concept of “Move Fast Without Breaking Things” at our User Conference in Washington DC in February, we have seen an overwhelming acknowledgement from our customers and partners that this is the perfect encapsulation of what modern application development and deployment means to them.
For Highly Regulated Large Enterprises (we call them “HRLEs”) software is developed in the most demanding environments in the world. With a myriad of technologies, a dispersed workforce, new compliance and regulatory demands every day, time-to-market time-frames often counted in hours and with every methodology possible driving velocity and every tech innovation driving disruption these organizations face a critical challenge. How exactly can you “Move Fast Without Breaking Things?”
This summer we will see how that is achieved in the “Summer of Speed” launches of four of Serena’s flagship solutions.
In June we will have the first of these launches with our Release and Deploy solutions. These solutions are anchor-technologies for your DevOps infrastructure and are essential for your Continuous Delivery initiatives. With release frequencies accelerating and deployments stacking up on the threshold of production, sophisticated IT organizations, like those you find in the HRLEs, demand exceptional solutions to meet the challenges. Come back here for more information on Serena Release Control and Serena Deployment Automation.
In July the launch of our latest ALM (Application [Development] Lifecycle Management) solutions will be revealed. HRLEs need deep visibility into the activities of the development teams and developers need advanced tools to optimize their development efforts. This summer will see the fruit of the continuous innovation from the Serena development teams that will bring to life reality of a common platform for all the developers in the organization whether they are Agile or Waterfall or anything in between, whether they are developing for mobile or mainframe, for teams of 2 to 2,000, collocated or dispersed across 6 continents. Dimensions RM for requirements management and Dimensions CM for configuration management have long set the standard in ALM. These two solutions have been updated to bring new meaning to visualization as both a way to organize and manage the software delivery process. Watch this space for more information on Dimensions RM and Dimensions CM coming this summer.
As the leader in deployment automation, Serena is a proud sponsor of the Jenkins User Conference 2015 World Tour. Come visit us at our booth and meet our experts in DevOps, CI/CD and enterprise release management.
Network Learn Explore @ the largest gathering of Continuous Integration and Continuous Delivery experts on the planet.
Want to tap the collective knowledge of a vibrant community of CI/CD practitioners? How about being able to network with other Agile and DevOps practitioners, just like yourself, looking to learn what others are doing across the software delivery process?
Register for just $399 (US) / £399 (UK).
You’ll notice some exciting changes this year, including:
* at US East, Europe and US West.
Greg Hughes talked about the need to “Move Fast Without Breaking Things” and his first love … a 128k RAM, twin 320kb floppy, 32lb “portable” computer. He drove home the critical need of modern organizations to create an infrastructure environment that supports dev teams while, at the same time, ensuring control, visibility and compliance. Every organization is “facing unimagined challenges securing their software repositories” and he laid out a set of 5 best practices that can be actioned immediately.
In describing Serena’s product strategy each of Serena’s development leaders showed off the latest innovations in each of the product lines. With new releases of every Serena product in the last 12 months and two major product announcements today with the release Serena Service Manager 5.2 and Serena Deployment Automation 5.2 it was an important start for the conference. Dimensions RM showed off the first ever Requirements Visualization feature that lets users drag and drop requirements, dependencies and relationship right on to releases. Dimensions CM showed the ChangeSet Graph which lets you see development teams building and deploying code in real time. The ChangeMan ZMF team talked about their new, high-performance, migration tool designed to automatically eliminate the repository sprawl on the mainframe.
Keep an eye on Twitter and follow @serenasoftware and look out for #serenaxchange for the latest updates.
Well! We’re all set to go! We have a great agenda, a fantastic lineup of speakers and some fun activities planned. If you haven’t registered yet there is still time – you can register here.
Let’s take a quick tour of the highlights …
Of course we’ll be celebrating too:
Looking forward to seeing you there. Contact Victoria Tse today for special pricing deals.
If you are planning on coming to xChange I want to remind you that the early bird pricing expires on December 31st. Right now you can save $200 off the registration fee.
See you in Washington DC in March!
The best just got better.
With the release of ChangeMan ZMF 8.1 a new era of software development becomes possible for the mainframe. With over 400 customer requested ideas implemented and groundbreaking innovations in cross-platform SDLC support, this release makes managing software development, from idea to deployment more streamlined, more automated and more reliable than ever.
Leading enterprises are under pressure to deliver innovation rapidly to satisfy their customers, while maintaining high quality and integrity, and reducing cost and risk. Agility and accelerated application delivery is required but companies struggle to deliver mainframe changes at the pace that the business demands. New Serena ChangeMan ZMF v8 capabilities enable mainframe application teams to deliver faster and at lower cost without compromising the enterprise scalability or security.
Here are some highlights:
Serena ChangeMan ZMF 8.1 provides development, release and deployment support for both Eclipse and Windows environments. Developers, release managers and business stakeholders can manage mainframe deployments and releases from a distributed client. Development teams can develop code and manage changes as they transition across environments.
Customer-specific business rules can be implemented in COBOL, REXX or any other high-level language. Pre- and post-exits are implemented at strategic points within the ChangeMan ZMF workflow and are implemented and executed across both mainframe and distributed clients.
“We tested the HLLX feature and were extremely impressed at the flexibility in which we could modify the behavior of ChangeMan ZMF. This allows us to leverage the development process as a clear competitive differentiator.”
Simplified administration means setup and deployment of ChangeMan ZMF instances can be done in minutes ensuring dev and test teams always have the right resources when they need them
Over 450 additional feature enhancements improving performance, security, usability, development and administration are included
As the most innovative release in more than a decade ChangeMan 8.1 sets the standard that all others can only aspire to. This is the ideal solution for mainframe teams that are under pressure to deliver high-quality, valuable software in an efficient, fast and reliable manner.
ChangeMan ZMF 8.1 highlights the continued investment that Serena Software is making in this strategic product used by hundreds of the world’s most important companies.
And there is more just around the corner. Watch out for next month’s release of ChangeMan 8.1 Client-Pack.
We are gearing up for our next global user conference, xChange15, to be held March 22-25 in Washington D.C. Like our past xChange conferences, this one is going to be all about helping our customers get the most value our of their Serena software investments, with presentations and workshops featuring the best thought leaders, technical experts, fellow customers and technology partners.
In three jam-packed days, we provide over 60 technical sessions on the products you are using today, like SBM, Dimensions CM and RM, Serena Release Manager, ChangeMan ZMF and more. We are working on the full agenda right now and will publish it as soon as available.
All available information about xChange is always on the xChange website at www.serena.com/xchange.
Discounted registration is available through the end of this calendar year, so take a look at your training and conference budget in 2014 and decide to spend it on attending xChange. You won’t be disappointed!
A few things to note for xChange15:
I look forward to seeing you in Washington D.C. in March!
Like most jobs in life, preparation is the key to success. After getting to know the Serena Deployment Automation technology by working with the free version (download from the Serena website) for a few hours (see yesterday’s post) I decided it was time to try for real.
My application was a Library Management System I developed a while ago for a public library in the United Kingdom. Like most developers I like to have something familiar to play with when I am learning a new technology.
So I started by defining my application to Serena Deployment Automation (SDA). The truth is that the help system (which is very helpful) suggested I defined the Components first. Partly because I like to try and test things to their limits and partly because I like to do the unexpected.
To start I clicked on Management, then Application and then Create New Application. I gave the application a name and a description and I was done. Easy. But was it too easy?
Once my application was created it dropped me into the Environment definition page. I was expecting this because I had been through the tutorials and samples when I first downloaded the Appliance. Here is where we define the target environments for the application. Every application lives somewhere. The environments are definitions of the locations you will be deploying to for development, testing and production. Each environment can comprise of one or more targets.
I clicked on Add Environment and the drop down menu invited me to pick from DEV, INT or QA. Well they didn’t suit me so I realized I needed to create my own Environments.
So now my plan was off track and that made this whole thing even more fun.
I clicked on Environments and there were DEV, INT and QA. So I clicked on Create Environment and all I had to do was to give the Environment a name and description. Next I was shown the Environment Details page. It had no details of course because it had just been created.
The Application was yet to be associated with the Environment and it had no resources. It was then it dawned on me. My application comprises of three parts. The database, running all the time, the programs running when invoked and the scripts that run once each time the application is refreshed. These resources, these components could go to any of the servers in my environment. I needed to define these components so I could tell SDA which components go where.
So I should have followed the instructions after all and defined the Components first. Good to know the help system has my best interests at heart. Even though I went down the wrong path all the entries I made are going to be used when we get down to the deployment itself.
So I now click on Components and the Create Component button.
Here I am invited, as usual, to give my Components a name and Description and, in addition, details of their location and the repository type. SDA supports almost 20 different types of repository including PVCS, Dimensions and Subversion.
My foundation is in place. Now I have to fill out a little more of the details and decide how the deployment should go. This whole process took no more than 5 minutes. In that time I had set up the Environments, the Application and the Components.
What I really want to do is deploy my Application and its Components through the sequence of Environments I have set up. To do that we need to define the process we want the deployment to follow. And that is what we’ll do tomorrow.
A couple of weeks ago I wrote about downloading the new Serena Deployment Automation Appliance. This is the free, community edition of the exceptionally advanced Deployment Automation technology we introduced last year. You can get your own copy, free forever, at the community edition website.
Since that post I have been working with the Appliance learning how to automate deployments. For about half an hour each day, for the past week, I have been pressing buttons, dragging and dropping and generally putting the technology through its paces partly to improve my understanding of how it all works but mostly to see just how much better automation is than the manual processes I used to use. I have to say I’m impressed! Let me take you on my journey and share with you how I became an automation-maven in just a week. In order to make this digestible I am going to write it in 5 separate postings.
Serena Deployment Automation divides the aspects of deployment into 3 units of deployment:
Each of these has associated attributes, the most important are: