Ship It!
•Download as PPTX, PDF•
0 likes•674 views
Salesforce, Google, Facebook, NimbleUser -- To be sure all of our customers are using all of our best work, software as a service peeps rollout software fixes continuously, and major versions several times a year. Learn what best practices we use to ensure each release is better than the last, with take-away pointers as to how you can use similar techniques in your own organization.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to Ship It!
Similar to Ship It! (20)
More from Ted Husted
More from Ted Husted (19)
Recently uploaded
Recently uploaded (20)
Ship It!
- 2. Ship It! Presented by: Ted Husted, Release Engineer Derek Hansen, Lead Engineer
- 4. Ship It! Do your best work using our best version. Always.
- 6. Delivering Nimble AMS Begin with the end in mind Put first things first Be proactive
- 7. Begin with the end in mind
- 11. Create Read Update Delete
- 12. Business Rules
- 13. Help Topics
- 15. Acceptance Tests
- 16. Begin with the end in mind The longest journey begins with a single step. What’s the simplest thing that can possibly work? Trust but verify. Information at your fingertips. Agility is in the details. Fail fast, fail often, fail safe.
- 17. Put first things first
- 18. Agile Board
- 19. Feature Orgs
- 20. Epic Success
- 21. Peer Testing
- 22. Code Review
- 23. Sprint Backlog
- 24. Put first things first Plan the work, work the plan. United we stand, divided we code. Test until fear turns to boredom. Given enough eyeballs, all bugs are shallow. Working code speaks.
- 25. Be Proactive
- 27. Help Topics
- 28. Delivered!
- 29. Preview Channel
- 30. Be Proactive Done and Done. It’s suppose to be automatic, but you still have to press the button. Change is the only constant. Look before you leap.
- 31. Think Win! Win!
- 32. Synergize
- 33. Take Aways
- 34. When - Release Cadence
- 36. How - Process
- 37. Who - Develop, Validate, Deploy, Support
- 38. Where - Production / Sandbox
- 39. Take Aways Ship no line before its time. Say what you mean, mean what you say. There’s a SMART way to manage goals and objectives. Coordinate. Orchestrate. Integrate. Location. Location. Location.
- 40. Thank You for Attending “Prioritize. Organize. Simplify.” Contact Us: Ted Husted ted@nimbleuser.com @tedhusted Derek Hanson derek@nimbleuser.com @nimblederek
Editor's Notes
- What’s the simplest thing that can possibly work? To build on feedback from early adopters, we want to start with the essential set of tasks needed to form a complete system. The Minimum Viable Product feature set is designed make necessary tasks easy and other tasks possible. The MVP is enough to increase your productivity in new ways, but, by design, it does not include any bells or whistles.
- The simplest example of a Minimum Viable Product might be the four core database operations: Create, Retrieve, Update, Delete -- or CRUD. Taken together, these four operations create a complete lifecycle. We can store a new record and bring it up again later. If state changes, we can revise the record, or remove the record altogether. If we take any one of these four operations away, the lifecycle is broken, and, like a dinner table with a missing leg, the system wobbles and falls. A competitive database solution will sport a cornucopia of other operations, but without these four, the table won’t stand.
- To be sure the MVP has a balanced foundation, we ”trust, but verify.” A pithy headline and a bubbly press release is a great way to layout the panoramic vision of a solution -- but a narrative is hard to test. To verify the solution, we need a concise, concrete punchlist of what it is suppose to do, and not do. Back in the day, we verified a system against a thick forest of “the system shall” statements. Then, on many agile projects, the “shall” requirements morphed into user stories, like “As an administrator, you need this so you can do that for some benefit”, or “Given a state, when some input happens, then some output happens.” Nowadays, for Nimble AMS, we just use simple, affirmative statements, or business rules, that are easy to code and test, like: “Order entry pages can be filtered by entity.” The business rules are the foundation of everything else that we specify in the solution. If we first validate that the customer will be happy with the business rules, and the features implement the rules, and the tests verify the rules -- then the solution meets the definition of done.
- Information at your fingertips. The press release helps us get our arms around a solution, but when people are using the product in the wild, we need to chunk the day-to-day documentation so that it matches the user experience. Online help lets you learn as you go. You can learn what you need to know when you need to know it. By writing help topics up front, we can flesh out the workflow details from the user’s perspective, and then deliver the topics to the online help site when the solution ships.
- Agility is in the details. To help folks customize Nimble AMS, we publish a number of developer overviews that outline the design of the various modules. The design outline includes the objects, pages, and classes used by the modules, the underlying logic, and the relationships between components. Just as we write the help topics first, we now use the same format for our design document that we use for the developer overviews. Once the solution is code complete, we break out the new developer overview as a separate document, living with the other overviews.
- Fail fast, fail often, fail safe. Test first development is a popular coding technique. Here, a developer writes the automated unit tests first, and then writes the code needed to pass the tests. The thinking is that, since we will need the tests anyway, why not write the tests first, to be sure the code is always fully tested. By marching through the business rules, we can draw up a full suite of user acceptance tests before the code is written. When we think through the tests, we have to work out a number of low-level details that must be decided before code can be finalized. If these details are not available, coders often have to stop, and hunt down the decision maker for clarification. (Or, just make something up.) So, since the code needs to be tested anyway … “dot-dot-dot”
- We don’t believe in cutting corners just to save a few steps. We do believe in starting with the simplest thing that can possibly work, and letting it grow into the solution that best meets your needs. We also believe in creating earlier, the resources that we will need later, so that they can help us along the way.
- While we create the working code, we use several techniques to help us focus on prioritization, communication, and coordination.
- Plan the work, work the plan. The technical solution breaks down the feature set into tasks that can be completed in a day or two. We follow the progress of each task on an agile board. We use a fancy software-generated board, but a lot of folks still use notecards or Post-its with good result. The board helps us stay proactive by mapping out the key stops on our agile train -- all aboard!
- United we stand, divided we code. At any one time, we have several different people working on a range of features and fixes. To keep us from stepping on each other, we create our own complete copies of the product -- usually one copy per feature or fix. Using a software version control tool called Git, we can merge the individual copies back into a shared copy, or “branch”. The next set of features branches are then created from the updated shared copy. The shared copy that we use for work that is ready to release is called the “develop” branch, or the “head”. For the Salesforce work, we use the metadata migration tool to push the latest version of the product from a feature branch into a trial org or sandbox org, or from the develop branch into our packaging org. To close the loop, we use an IDE tool, like Eclipse or Mavens Mate, to synchronize the changes we make, and then use Git to push the changes back to the feature branch.
- A great restaurant not only prepares a fine meal, it plates the dish. Before we serve up new code, we pass the plate to our readiness squad, who add the finishing garnish.
- Done and Done. In an environment that includes all the newly written code and code changes, a second person on the readiness squad runs all the automated tests, and walks through all the acceptance tests. One. More. Time. During readiness testing, we try to both verify and validate our work product. We ask not only “Did we build the thing right?” -- with all the working bits in front of us, we also ask: “Did we build the right thing?”. Software that “operates as designed” is only as correct as the design itself.
- It’s suppose to be automatic, but you still have to press the button. As much as we would like Nimble AMS to “just work”, we know that sometimes people need help getting started with a new process. Our help.nimbleams.com site sprung from the training materials that we use when a customer first goes live. It’s a good start, but we need to grow it into a reference that you can use a on day-to-day basis. As part of the readiness review, we step back and make sure that existing content is up to date, and that we are adding any new topics needed to cover new ground. We maintain the help site using the same branching techniques we use with Apex and .NET code, so we can roll it out altogether at the appointed hour.
- Change is the only constant. Like Salesforce, we deliver major new features three times a year, and continually update the product to address other issues as they arise. When a fix becomes available, we generally push it to the customers who reported the problem first, and then to the rest of the customers the following Wednesday, at 9 PM eastern. We log all the changes, major and minor, on our Delivered! page, which is updated any time we deploy a new version.
- Look before you leap. Coming up to a seasonal release, we upgrade the customer staging sandboxes with new version, and run a suite of regressions tests, to verify that all is well and good. We also publish the preview help site, with our release notes, so that everyone can see what’s coming. The customer preview is actually the last stop on a series of previews that we create during the development process. As we reach milestones, our internal testing orgs are updated to the latest preview, so our folks can jump in and kick the tires. Sometimes, a new customer, who is going live after the next release, may be on the preview channel, so that they can make best use of the newest features, when they first go live. When the seasonal release rolls out, we update all the active orgs, so everyone is on the same version again. That’s progress for ya!
- Release readiness is a continuous, proactive process. As each sprint closes, internally, we not only deliver an increment of the software. We deliver an increment of everything that goes into a release. When the seasonal release train leaves the station, we already have everyone on board, with tickets punched and heads counted.
- Our release is only successful, if you are successful. To help us help you, we gather together key resources in the Nimble AMS release center. During the customer preview, the release center offers quick access to the updated documentation and release schedule. The rest of the year, you can return to the release center for quick links to Help, Support, and, of course, NimbleLand.
- NimbleLand is our virtual water cooler, where we can hobnob and smooze, and work together to make Nimble AMS the best that it can be. If you can’t find what you need anywhere else, just click your ruby slippers, login to NimbleLand, and ask!
- Of course, all that’s well and good, if you’re delivering a mammoth product like Nimble AMS. But how can you apply the practices we use to smaller projects?
- First, think about how often you want to release. Do you want to ship according to a set schedule or as needed? If you already have a backlog, the rigor of a release train can help you steadily reduce the stack. Of course, the nature of backlogs is that they tend to increase, but with a release train, at least you can see regular progress. If you don’t have a lot of outstanding work, then releasing as quickly as you can may help keep it that way. If you need to do both, as we do, then be sure to organize your work so that the long term work-in-progress doesn’t mix-in with shorter term work. Ship no line before its time.
- Human language is imprecise, which can lead to misunderstandings over what is being delivered in a release. As you plan what to deliver, assign a unique identifier to each work item, so that you have an unambiguous way to refer to exactly that item. Be sure to refer to the identifier in whatever checklists or plans you use to manage a release. Then there will be no question as what’s in and what’s not. Say what you mean. Mean what you say.
- The best deliverable is a SMART deliverable. For each work item, be sure to describe it in terms that are specific, measurable, achievable, realistic, and time-scaled. Specify exactly what is going to be done, and how you will measure success. Indicate how you know the result is achievable, and whether it’s realistic for you to deliver the work item with available resources. Then, time-scale the deliverable by deciding where it fits into your release cadence. There’s a SMART way to manage goals and objectives.
- Be sure you understand who will create the work item, test it, roll it out, and help people use it afterwards. Coordinate, orchestrate, integrate.
- For some deliverables, you will want to do the work in a sandbox, and then change set the components to production. Other times, you might want to create the work item directly in production. Either way, be sure to coordinate the work with anyone else who might be working in the org, so that you don’t overwrite each other’s changes. Location. Location. Location.
- The core best practices for release engineering apply to any size project. To be successful, you need to be SMART, and pay attention to the five Ws. The rest will follow.
- Creating an effective, agile release process is not something you can put together on a rainy afternoon,. But if you start with the simplest thing that can possibly work, you can refine the process release after release, until you have a routine that fits like a glove. Any questions?