Developer Community   |   Fellowship Technologies   |   Dynamic Church Conference

Design Patterns Library & Code Standards

• Design Patterns
• Code Standards
• API Code Standards
• Continuous Delivery

Continuous Delivery

Reliable Software Releases through Build, Test and Deployment Automation

---

Dark side

Pushing new features dark

A module should exist for any new feature being developed. The module state must be interpreted by the code that is being developed. This will allow for the feature to be dark for zero, one or many tenants. This allows for a finished feature to live in production without any tenants having access to it until it's decided to be generally available. This also allows a feature to live in production and be visible for tenants such as test tenants or sales tenants without exposing the feature to the general public.

How:

• Modules (ex. giving modules)
• Hide endpoints in our applications if web based
• Use obsolete tags once the feature is "released"

Why? By using this form of filtering features we can accomplish several things:

• We can push new stuff dark
• We can provide certain sets of users with access to the new features
• We can gain the benefits of feature integration without exposing the feature - so CI and unit tests can run and "prove the functionality"
• We can use "static" validation in our CI to prevent code stale - allowing use to incrementally remove module checks when things become released

Using modules

Using in code modules to hide features

Using a module via controller attribute

[ChurchModuleFilter(ModuleType.OnlineGiving)] public class HistoryController : BaseController { ...

Using multiple modules via controller attribute

[ChurchModuleFilter(ModuleType.OnlineGiving, ModuleType.ScheduledGiving)] public class ScheduledGivingController : GivingWizardBaseController { ...

Using a module via action attribute

[ChurchModuleFilter(ModuleType.OnlineGiving)] public ActionResult Index(){ ...

Using a module via conditional

if (this.CurrentChurch.Modules.HasModule(ModuleType.OnlineGiving)) { //functionality }

Hide endpoints

Hide endpoints using conditional code or overloaded render methods

Hide endpoints in code

<%if (this.CurrentChurch.Modules.HasModule(ModuleType.OnlineGiving)) {%> <a href ... <%}%>

Use obsolete attributes

Remove modules of released code by implementing the obsolete attribute.

Decorating the module type with an obsolete attribute

[Obsolete("dark module was deprecated on 03.10.2011")] OnlineGiving, Directory, Groups ...

Make changes incrementally

If possible, break things up into components that provide value to the customer and our organization, and so that they are timely, and so that they provide value to achieving continuous delivery. Look for ways to break down user stories that will still deliver value to customers while limiting the amount of development and tested, in general, in two to three days.

How?

• Smaller, releasable units of work - what the product owners and the team are working on now
• Incrementally introduce new features on existing pages that will not drastically change the way the page / application functions
• Incrementally seek out refactoring opportunities that change architecture and or system behavior but not feature functionality (excluding performance as a feature)

Why?

• We can provide features to users more quickly
• We can verify integration while continually releasing things
• We can provide business value to business applications without causing the need for training

Use obsolete attributes

By using obsolete attributes we can develop code in parallel so that legacy code / functionality can be easily deprecated at the appropriate time.

Decorating a properties or classes with an obsolete attribute

public class User{ public Individual Person {get; set;} [Obsolete("Property has been replaced by User.Person.FirstName")] public string FirstName {get; set;} ...

Use branch abstraction

When functionality is in development, create branches based on user story or feature set. The branch's intention is to separate incomplete code from master so a release can happen and any point in time without fear of incomplete code getting to production. When a user story or feature set is complete (both from development and QA) a pull request is initiated to merge the branch code into the master set of code.

How?

• Rewrite customer facing applications in parallel, until the old is deprecated and the new provides equal or greater functionality and performance
• Change underlying architecture by using obsolete tagging and writing parallel implementations then drop the abstraction when done
• Replace systems components using parallel processes

Why?

• It helps us get away from our ball of mud patterns and move to more structured patterns
• We can refactor without seizing development or applications
• We can deprecate without destroying or compromising other applications in our platform

Use feature branches

By using a distributed repository such as GIT we can easily create and distribute branches where all team members can work on single features without impacting other development

Branching using GIT

git checkout origin master git pull origin master --create branch and track master git checkout -b feature-1234 origin/master