ACCUREV BLOG

Making Git in the Enterprise a Reality

Developer:  I love using Git.  It’s so easy to work with, and I can code quickly with it!  I’d like to use Git for our XYZ project.

Manager: I realize that you really like using Git, but we need to figure out how we can let you use Git and still manage the security and scalability issues with it in our enterprise environment.

Does this sound like your software development organization?

Just about every software developer has heard of Git, the open-source version control system that’s easy to setup and use, powerful, distributed and most importantly, fast. You may love using Git, particularly if you are working with Android or Linux, but if you are within an enterprise software development organization, the reality is that Git alone is not the answer. Although Git works well and enables developer productivity, it has limitations that impede software development efforts in an enterprise environment.

One of the limitations with Git is that it poses a compliance and audit risk. Development history can be changed and you can’t verify that each change in production was tied to a particular change/issue request, or oftentimes which developer originated the change, For companies that have to meet specific regulatory requirements, you need an audit trail of changes, which Git does not inherently provide. Git also lacks built-in security, giving everyone access to everything, which is an issue if you are managing larger, enterprise software development organizations where only certain people should access certain code. So, while Git has many benefits, it also presents lots of challenges if you work on large-scale, enterprise software projects.

But you can realize the benefits of Git and scale it for complex enterprise software environments.

AccuRev developed GitCentric with all of this in mind. With GitCentric, you can maintain control, security and traceability – all critical in large, complex development organizations- while working optimizing your agile and continuous integration and delivery goals.

We recently conducted a webinar on this topic. Check out: http://bit.ly/1b3rsEH for more information on Git, including its challenges and benefits, and how you can leverage it effectively and securely in the enterprise using GitCentric.

Carol Ferrari – Vice President, Marketing – AccuRev

Posted in: Uncategorized

Leave a Comment (0) →

Developing Legacy Software Doesn’t Mean you Can’t Also be Agile

Having spent a significant amount of time in various engineering and development organizations, I have had an opportunity to encounter a variety of challenges ranging from overseeing multiple development projects, to managing offshore outsourcing, to reacting to and addressing increased competition and evolving customer requirements.  With a couple of those challenges along side the task of developing legacy software and a desire to adopt an Agile development methodology, it may seem like the odds have not been in my favor.

Over time, I have come to an understanding of how to balance the desire to elevate Agile practices, while developing legacy software. Throughout my career, I have at times seen these two objectives at odds with one another – but the good news is, this doesn’t have to be the case.  There are steps development organizations can take to be Agile, despite the roadblocks that developers working on legacy software may have.  Here are three processes I recommend for successful Agile development while developing legacy software:

  1. Create a legacy model – Agile modeling includes the Formalize Contract Models practice.
  2. Move forward with small, evolving changes – work towards a roadmap.
  3. Create an Agile culture – this includes new lingo and creating excitement around change; time boxed releases; customer feedback after key sprints are completed; a scrum-of-scrum team that monitors the releases and impediments such as builds, process and capital purchases, etc.

While the above steps are important, it’s also critical for your organization to keep in mind there are things that can break Agile – and keys to make you more successful.  For example, the definition of “done” needs to be one that teams can actually achieve.  If you are setting yourself up for failure, that’s exactly what will happen.  Don’t forget you need to have a means to validate that Agile is producing results, like story boards and release burn down reports, as well as testable code. Another key is to ensure that development is fast, with frequent code integrations (continuous integration).  Finally, and sometimes the most important aspect of Agile, is that your team members need to fully function as a team – if you have members that are controlling and don’t let others speak, the process will break down very quickly.

We recently conducted a webinar on this topic, which you can watch here:  http://bit.ly/GYhYOc.

Larry Ayres – Vice President Engineering and Support – AccuRev

Posted in: AccuRev, Agile, Best Practices, Continuous Delivery, continuous integration, cross-functional teams, Enterprise Agile, Legacy Software, Scrum, Software Configuration Management, Tips and Tricks

Leave a Comment (0) →

When is software really “done?”

During a meeting I recently attended with a services company, the topic of their definition of “done” during their software development process came up. For them, software was considered done when developers checked in their functional code and it had passed basic unit testing criteria. This discussion really got me thinking…how are other companies defining “done” for their software development process. And more importantly, do they truly understand the impact their definition has on their overall quality and software delivery process?

watchcomponents 221x300 When is software really done? When I think about done, I think in terms of varying levels of code maturity, with each level progressing higher, resulting in fully mature code at software delivery. At its basic level, “done” can be defined as having software code functionally complete (done = functional), as was the definition we discussed at this meeting.  Specifically, story acceptance criteria must be achieved and satisfied through testing. If an organization is measuring “done” using Agile planning at this level, they may consider the software development process at a base-level of code maturity. For me, functionally complete software equates to having all components coded, unit tested, and all story acceptance criteria satisfied. I equate this basic level to that of the beginning phase of constructing a fine timepiece. Each component that goes into the watch has been masterfully crafted, tested, and completed. However, at the end of the day, you only have the components that can make up a watch; you still don’t have a watch.

 

Progressing to the next level of code maturity shifts the focus from having functionally complete stories to having integrated integrated watch 300x250 When is software really done? stories. Measuring “done” at this level requires software meet a different set of criteria; software must be integrated, checked into trunk, and must pass all commit stage test and validations. Companies who have embraced a Continuous Integration approach to software development often find themselves achieving this second level of code maturity and definition of done (done=integrated). Organizations which have achieved these 2 definitions of done; functional and integrated, often find themselves delivering code which still has issues. Why? – Bringing all of the components and pieces together is often times an art. Organizations have to understand how it all comes together in order to ensure the highest levels of software quality. As with a fine time piece, integrating all of the components is what gives the watch its beauty, function, and purpose. But even fully integrated, the watch is not complete.

 

This leads us to a third level of progression for code maturity and definition of done (done=delivered). In this level of code maturity, software is “done” when; it is delivered and has passed all regression, functional, and non-functional testing.  This third level of progression is a key principle for organizations looking to embrace Continuous Delivery within their software development processes. Implementing the various levels of progression or definitions of “done” for any software organization rely on the alignment of technology, process, people, and values.

watch 180x300 When is software really done? As a consumer, and a self-professed lover of luxury time pieces, taking delivery of a piece of art is always a highlight. Understanding what went into making it, well that just makes delivery all the more special. Software development in many regards is also an art form, with developers putting their creative touches in their code and their products. As such, software development organizations must ensure they have the right processes and disciplines in place to deliver their products to the market quickly, with high quality and predictability. Understanding the need to have varying degrees of “done” is essential for software organizations to maintain high-velocity  in their development processes and to keep software continuously flowing through these tiers of code maturity.

 

Chris Lawrence – AccuRev

 

 

 

Posted in: AccuRev, Agile, Best Practices, Continuous Delivery, continuous integration, Patterns, SCM, Software Configuration Management, Uncategorized

Leave a Comment (0) →
Page 1 of 77 12345...»