Showing posts with label ALM. Show all posts
Showing posts with label ALM. Show all posts

Friday 8 September 2023

Notes for running Agile Power Platform Projects including DevOps

Overview:  General overview notes on setting up Power Platform projects/programs.  Before I get into the mechanics, my overriding goal is to have high functioning teams, and be a member of high functioning teams.  "Create an environment where team members can do there best work".  for instance, I visit and work with a lot of businesses and I many teams that are in an "Artificial Harmony" state (pretend all is well with the world). Everyone says it's wonderful but it's a snake-pit with relationships and fear.  Teams members need to be happy, open to conversations, accept risk and aware mistakes are going to happen.  Basically, these teams need to be identified and trust build, this often involves an adjustment to a particular mid-level manager.  The worst offenders tend to be offshore teams, and there are amazing teams and people so this definitely is a generalization. The teams tend to be hierarchical as opposed to flat or matrix. it's terrible for software projects.  Look out for Technical leads, ISV Project managers, Deliver Leads, they can breed the wrong tone/attitude across multiple team members and teams.  Check out Amy Edmondson's book the Right kind of wrong: the Science of failing well.  Anyway, rant over.   

Learn from mistakes, simple mistakes, remove them ASAP, strategically think automation, if we learn mistakes ensure they don't happen on the next project or sooner.  Encourage transparency, and open communication.


Here are my notes for setting up ADO and guidance for Agile PP projects....

Agile Artifact Hierarchy:

Epics > User Stories (max 5 days work) > Tasks 

                                                                  > Bugs

Epics > Spike

Guide:

  • User Stories mush be written in the format: As the <role> , I want to <feature> so that <benefit>., and have 1 to many Acceptance Criteria using Gherkin 
  • Ability to add a release note to User Story, Spike, Task or Bug.
  • Automate pipelines from unmanaged to UAT Managed.
  • Min three env (Dev-unmanaged), and UAT/Prod-both managed), use ADO pipelines or Power platform pipelines
  • Adding annotated images is great for improved communication.  Recorded voice narrated mp4 walk thrus are also great for proofs, and explaining issues.
  • US, bug, Task, Spike artifact items, each has a Release note tab.  So if a User Story needs more than 1 solution package changed, use child tasks and add the release notes to the User Story.

Flow of bugs and User Stories:

  1. New (Anyone)
  2. Approved (Product Owner (PO)) 
  3. Ready - (PO)
  4. Committed - (Team Member/dev)
  5. Dev - In Progress (dev)
  6. Dev - Complete (dev)
  7. Dev - Show QA (dev & QA)
  8. UAT - Ready to Deploy in UAT (dev)
  9. UAT - Deployed Ready for Testing (QA)
  10. UAT - In Tested Manaual (QA & PO)
  11. UAT - Complete Ready for Deployment to Prd (QA)
  12. PRD - Deployed
  13. PRD - Sanity Check (can include automate smoke testing)
  14. PRD - Done
Example Status's
Other states:

  • Removed
  • Duplicate
  • Not Applicable

Release Notes for Power Platform packages need to include the following fields in ADO against artefacts:

  1. Package Name (dropdownlist), 
  2. Current Package Version, 
  3. New Package Version (Default TBC), 
  4. Change Note,  
  5. Deployed Status (dropdown list: NA, UAT, PRD), 
  6. Pre deployment steps, 
  7. Post Deployment steps
Example of ADO Release Notes assigned against tasks, bugs, and user stories.

Quick fixes/urgent bugs/Emergency changes:

  • Try make release cycles as short as possible, and only do emergency changes if absolutely required.
  • Take a snapshot copy of dev/label, for each proposed production deployment - unmanaged env - part of ADO pipeline, this allows us to build Dev, and UAT env for the specific emergency change.
  • Take a snapshot of UAT - managed env - part of ADO pipeline
  • Deploy to PRD from Emergency UAT.
  • Developer integrates emergency change into Dev from the Dev Copy.  And follows the full path.
Team/Teams:
  • Try keep teams as small as possible.  I prefer 1 team to multiple scrum teams unless their is a clear distinction/break.
  • Product Owner (PO) needs to be available all the time and answer immediately.  To me they act as the business and the traditional BA role, and are responsible for the product backlog.
  • Scrum masters.  Your job is to ensure the team members are happy and confident to take risks and work, Scrum ceremonies are merely a way to help out.
  • Team members are mainly pro and citizen developers, if I use dedicated QA testers in the scrum team, they need to be responsible for the AC with the PO.  They tend to be analyst/developers.
  • Automate, automate, automate.  there are fantastic tools including low code test tools, use them.  Ensure you have automate smoke tests, regression tests, and performance tests for each DTAP env.
  • Have short coding standards and naming conventions, error handling patterns and enforce them, have a defined ADO process, have a pipeline for deployments, automate tests and continuously update.  Have a Monitoring strategy i.e. Azure Monitor, log via AppInsights on a Log Analytics workspace.  Each env logs to it's own Azure Log Analytics.  Does each Log analytics belong to their own workspace?  I pref Non-prod, and prod workspaces. 
  • Teams/Slack, okay just Microsoft Teams, remote work make happier team members and gives people more time, use it.  But encourage camera to be on, email is not a defence (ever), people must IM/chat/ping and call each other.  
  • Encourage meeting up, join with social inclusive events at once a month to once a week.  Encourage people to work together online including peer programming.  

Friday 24 February 2023

Environment variables for Power Automate

Overview: Environment variables are great in Power Platform but when using managed solutions and ALM there are a couple of points that will make your deployment and support easier.

Background:  Power Platform has Environment Variables (env vars) that are sored in two entities within the Dataverse namely: definitions and values.

We deploy env vars thru solutions and can easily amend with adding an unmanaged layer.

Problem:  In you managed environment you end up with a tangle of env vars that make upgrading solutions fail.  in a nutshell, deleting unmanaged layers using the UI, only clears the value of the env var variable part. And not the definition part. The unmanaged later env var is made up of two parts and stored in the 2 environment entities in the Dataverse.  Both must be removed.

It makes sense as in UAT we have env vars initially setup in a solutions, then we have unmanaged layers added when we amended the values, then later we use a different solution to deploy the latest env var from a different solution.

What I have seen is env being deployed as part of a 1 solution for all artefacts approach, as the project grows more solutions are added for packaging and each of these solutions has a few more env variables.  Eventually as you use the env vars across multiple Canvas apps, Power automate instances, you build a dedicate solution for env vars.

Best Practice:  Well what I recommend at least

  1. Put all variables into a single solution from the start, it means it is easy to deploy them quickly across all your DTAP environments e.g. uat, Prod.
  2. In the unmanaged solution ensure the env variables do not have a "current value".  Set the "default value" in Dev.
  3. Run settings files to fill the "Current value" in each DTAP env, have the current values for each env in a single settings file that will push the settings via the pipeline i.e. setting-uat.json, setting-prd.json
Tip: If you need to change any value merely rerun the solution containing the env vars, don't ever use an unmanaged layer to change env vars.

Tip: It's better to build your Power Platform environment in DevOps pipelines but if you use existing environments and merely push solutions on top (much more common), then clean up your existing vars as outlined below.
  1. Delete both the definition and variable parts (manual) until the environment UAT, PRD has no custom env vars. - use the Dataverse meta api
  2. Run the single env var solution.
  3. Never add unmanaged layers to env variables, if you need it changes, change the solution package and deploy, should take minutes to do. 

Friday 28 October 2022

ALM Power Platform - Problem Solving

 Use the logical name of the embedded canvas app

Problem:  I have embedded canvas apps inside a Model app that I deploy via a solution.  When I move from Development to Test, the users reported that they don't have access "This app isn't opening correctly" "It looks like you don't have access to this app."  And when I dive deeper, I see the Model app in Test is point to the Development Canvas App; not the test canvas app.

Initial Hypothesis: My thinking is that the Model App in Test is pointing to the Canvas App in Dev.  In dev, I point to the test canvas app and it works.  The workaround is to Open the managed solution in the Test environment and change the AppId  to the App Id of the canvas App in TEST.   It works but it's an awful work around.  This tells me that my App Name is not working, as the Static App name is used before the AppId (looks for the app name in the current environment) and then the AppId when the app Name doesn't resolve, I believe the app name is not working.  

I changed the AppId (to a non-existing guid) and the app wouldn't load in dev.  The app name should be the logical name and not the display name.    

"The App Name property specifies the name of the canvas app to embed. The model-driven form looks for the canvas app with the specified name in the current environment. If a canvas app with that name can't be found in the environment, the canvas app control will use the App ID to load the canvas app. Enter the App Name for an existing canvas app."  Add an embedded canvas app on a model-driven form - Power Apps | Microsoft Learn

Resolution:  Open the table > Forms > Form containing the canvas app


Or, another alternative is to use Environment variables for all the canvas AppID's and change them per DTAP environment on the deployment.

More Info:

Guidelines and troubleshooting when working with embedded canvas apps - Power Apps | Microsoft Learn - scroll to "Known issues and limitations with embedded canvas apps", "The App Name property value is missing or is incorrectly defined"

Sunday 15 July 2018

Power Platform Notes - Power Apps, CDS, Power BI & Power Automate

Power Apps

Variables:
Microsoft Docs "PowerApps and Excel both automatically recalculate formulas as the input data changes".
  • Contextual variables - scoped at a screen level
  • Global variables - scoped app level
  • Fx> Set(MyUniqueClientNo, 12)
Functions:
Fx> UpdateContext({MyTimesheetId: 34})
Tip from Shane Young:  Note the setting variable may be the reference, so for a control use:
Fx> UpdateContext({MyTimesheetId: txtTimesheetId.Text}) not
Fx> UpdateContext({MyTimesheetId: txtTimesheetId.Text}) unless you want the context to float

Pass a variable to another screen use the Navigate overload, OnSelect property of a button
Fx> Navigate(Screen2, ScreenTransition.None, {TSvar: MyTimesheetId}
MyTimeSheet Id is a contextual variable

If Statement:
Fx> If(MyUniqueClientNo = 12, lblAns.text = 'yes', lblAns.text = 'No')

Environments:
  1. Power Platform allows you to create multiple environments, each environment is connected to you AAD tenant.
  2. Policies can be applied to prevent DLP against all environments or specific environments.
  3. Use Environments for DTAP, business units, or Extranet vs Intranet.
  4. Updated June 2022: Environments can be of type: Default (don't use and rename), Developer, Trial, Sandbox or Production.
  5. Each Power App environment can have no CDS/Datavserse or a single CDS/Dataverse connect.
Manged vs Un-Managed Solutions:
Solution are useful for packaging and moving assets between environments or tenants.  Manged restricts who can edit the applications in the solution.  I like to keep each solution with a single app in it.  On large projects, it's a good idea to keep environment variables, custom connectors, cloud flows, apps in separate solutions.  It makes it easier to deploy pieces.    

Managed Environments:
Don't mix up with Managed solutions as I did recently.  Managed environments allow for a host to control all the environments.  You also should use a dedicated host production environments with Dataverse database to control all the environments.  You need to install solution on the host.  Managed environment have no correlation to managed solutions.  You need managed environments is you are going to use Power Platforms simple ALM for App deployment.

ALM:
Power Apps has it's own source control and you can manually export and import entire projects "Export package" not connections are not export as part of the package.  Solutions are the best way to move code between environments.  It's a good idea to use environment variables  Get ADO, more secure, better tooling using solutions over manual exporting code using packages.  Power Apps Build Tools allows for ADO/DevOps integration generally using solutions to deploy.  At a minimum you should have your own dev env (Sandbox or Developer type), a test (Sandbox type) and production (production type env) for any serious app you build.

Add "Power Platform Tools"

Example Power Platform ALM deployment using DevOps - 5 environments

Update Jan 2022
Solutions are used to in Power Apps to package and move code and resources such as flows, env variables, canvas apps, Dataverse tables between environments.  It's a good idea to not use the default environment as everyone has access to the environment.  The DTAP around ALM can get pretty complex and I like to keep it fairly simple.  Connectors can get nasty in packaging.  ADO using AppBuild Tools makes for a good CI/CD solution for Power Apps.

Environment variables are a great way to manage configuration, they can also easily be configure in the pipelines to replace with the appropriate values.  Tip:  Don't ever set the current value in an env var it get carried thru to the next DTAP env.  Also env vars support Azure Key Vault, use it for secrets.

Custom Connectors and getting Connection References correct when using managed environments to deploy code need to use environment variables so they can easily be set for each environment using CI/CD.  It's a good idea to create connections in solutions and use a dedicate Owner account.  Connection references in solutions - Power Apps | Microsoft Learn

There is also a great tool to unpack .msapp solutions for raw review and storage in git.  https://powerapps.microsoft.com/en-us/blog/source-code-files-for-canvas-apps/ for me, it's main use is verifying code and standards and comparing versions.  Post on unpacking solutions.  You can also see how many controls you have in you Canvas app.  MS have the guideline of 500 controls in an app.  

Have a: 
  1. Dev environment that is of the "sandbox" type.  Have an un-managed solution that will act as your base canvas app for all new Power Apps.  When you export the solution remember to export as a managed solution and ensure environment variables are emptied before publishing the export.  Good place to backup to a repository such as TFS Azure DevOps/Git.
  2. Test env of the type "production" or "sandbox".  Only allow managed solutions to be deployed.  Watch out for custom connectors, I can't get them to deploy correctly in solutions.
  3. Prd env must be of type "production".
Manual ALM i.e. Use PowerApps to store Dev versions, Exporting solutions and unpacking managed solutions into UAT and production.  Manual ALM is good even manually moving the applications by hand is simple and safe.  There are backups and manual backups to avoid a source code repository.  I also like the testing framework in Power Apps.  Using the build tools getting full ALM/CI/CD it is easy to then move your Power Platform into a higher ALM CI/CD level using the Power Platform Build tools, DevOps, and PowerShell cmds.  
Update April 2022: Great simple video on ADO for Power Platform 

Licencing:
Updated: Power Apps Licencing Summary as of 30 December 2019
"To run standalone apps, guest users need the same license as users in your tenant."  Microsoft Docs.  
  • PowerApps using AAD B2B user (both members and guest) using standalone Power Apps shall require the Power Apps licence (not necessarily Portal Apps).  Steps to Share Power Apps with Guests
  • SharePoint user interacting with a Power Apps form on a SharePoint list do not require a Power Apps licence.
Coding Standards for Power Apps:
  • Microsoft provide a whitepaper as a suggestion for using naming/coding standards.
  • Controls and variables should use prefixed Camel case e.g. txtContactEmail
  • Data sources use Pascal Case e.g. ContactUsers 
  • Screen must be Full names e.g. Edit Contact User Screen as they are read as named by screen readers like JAWS and Microsoft reader.
  • Prefix controls and collections (Label is lbl, Textbox is txt, Button is btn, Collection is col, drop down lists are ddl, Form is frm, Group is grp, Gallery is gal, Icon is ico, Images are img, Table is tbl.  I also prefix my components with com.
  • Variable naming is: gbl for Global and context variables are var
  • Use Containers for layout and groups for control aggregation.
  • Use TabIndex so keyboard navigation makes sense.  Use the AccessibleLable over HintText.  Ensure colour contracts and use the approved colour templates stored in global variables.  All fonts, sizing and colouring must come from global variables so the app can be easily changed.  Use the App Checked and complete all identified accessibility issues/concerns.  Test on actual devices and use screen readers.
  • Ensure App Insights is setup, capture and log errors, also use the monitoring (maybe not in production).
Power Apps Portals:
Build responsive website using CDS.  Allow anonymous access or implement multiple Identity Providers (IdP) such as AAD B2C, AAD, Google+, LinkedIn.

Updated: 28 July 2018:
Common Data Service (CDS): Comes from Dynamics CRM Sales, pretty much used like CT's in SharePoint.
  • Based on Azure SQL & uses CosmosDB with a nice API that support REST/ODatav4;  
  • Has Row, field RBAC and uses AAD for authentication;
  • Allows Power BI, Power Apps (previously labeled as PowerApps) & Flow (Power Automate - new name since Ignite 2019) to work with CDS (renamed to Dataverse);
  • Use Power Query to Import data easily or data flows
  • Multiple data source such as SQL Server, Cosmos, files, Excel, Search, 3rd parties such as SAP.
  • CDS is not part of the O365 licencing (including E5), you need to get a PowerApps P1 or P2 (Now Power Apps for Users as licencing changed circa Oct 2019).  Note Power Apps licencing included with O365 is extremely limited and for instance does not cover CDS;
  • One Power Platform Environment ties to one CDS/Dataverse database
  • Any type of data; any type of app.  
  • Easy to use; secure.
https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-intro

Examples: 
Insert or Update using Patch to CDS:
Patch(
        Vote,
        Defaults('Employee Sentiment'),
        {
            userid: UserID,
            vote: ThisItem.Vote,
            votedate: Now()
        }
    );
Select from CDS:
UpdateContext( { locVotes: LookUp('Vote', votedate = <date>) });

Tip: XrmToolBox is a fantastic tool.  Multiple contributors have added to the client application, there are so many useful features for instance FetchXMLBuilder allows you to query the Dataverse tables.

Power Automate

Updated 11 December 2019:
Microsoft Power Automate (previously called Microsoft Flow, is an user friendly workflow tool/service): Simple workflow engine sitting on Azure Logic App.
Basic business process flows are:
  1. Automated Flows - used when event/status change e.g. CDS row status changes
  2. Button Flow/Instant Flow - Events such as a click triggers the flow;
  3. Scheduled Flow - in effect timer jobs;
  4. Business Process Flow - ensures users enter  data consistently (think Windows Presentation Framework) & follows the same steps every time; and
  5. UI Flow (preview) - Provides RPA capabilities;
https://docs.microsoft.com/en-us/power-automate/get-started-logic-flow

Building Blocks for Power Automation are:
  • Trigger - what starts the workflow, can be manual trigger or an automated trigger
  • Actions - ,
  • Conditions,
  • Data operations, 
  • Expressions - basic operations like adding two numbers together, making a string upper case, and
  • Flow Type - see the 5 flow types above.
Display directions using Map on a Image control in PowerApps:
https://dev.virtualearth.net/REST/v1/Imagery/Map/road/Routes/driving?waypoint.1=51.525503,-0.0822229&waypoint.2=SE9%4PN&mapSize=600,300&key=<key>
https://dev.virtualearth.net/REST/v1/Imagery/Map/road/Routes/driving?waypoint.1=" & EncodeUrl(txtDriverLocation.Text) & "&waypoint.2=" & EncodeUrl(txtDriverLocation.Text) & "&mapSize=600,300&key=AsR555key

Sunday 7 April 2013

Agile Software development for SharePoint


Overview

SharePoint 2013 brings new software development challenges to organizations.  Anyone architecting solutions involving SharePoint is faced with more critical decision points than ever before.  Traditional approaches to requirement gathering used on SharePoint projects, often include a long winded structure analysis phase.  It is expensive and difficult to get the relevant analysis clarified and Agile offers a different approach to working out what you are trying to achieve. 

The familiar IT Project Management Triangle gives one a clear visual representation of the constraints facing projects.  By using Agile management of projects can remove beaurocrartic redundant steps and focus on delivering what the customer is looking for.  This post provides an overview of using Agile methodologies such as SCRUM to help alleviate some of the problems we face when working with SharePoint 2013 development projects.


IT Project Management Triangle.
I am looking at SCRUM and Agile practices from a practical SharePoint delivery perspective.  SCRUM, like all methodologies, has it’s time and place.  SharePoint 2013 has many visual quick win so it is easy to get visual ideas in front of the end client very quickly in an iterative approach.

Supplementing project management with Agile practices and techniques to move a project towards successful delivery should overrule any historic dogmatic approaches.  

Methodologies

For simplicity, I break down the various software development methodologies into two main camps:

• The traditional approach that the Systems Development Life Cycle (SDLC) falls under and
• Agile Methodologies (SCRUM being the most common framework of Agile, other frameworks include Agile Kanban, Extreme Programming). 

SharePoint projects are all too often run using traditional approach that can result in “analysis paralysis”.

Agile methodology is implemented normally using an Agile Framework such as SCRUM which is by far the most popular framework.  As with anything, context is all-important.  The approach and techniques need to make sense to your organization and the project.  A good technical lead or Solutions Architect picks and borrows specific parts of different framework or methodologies when providing SharePoint solutions in order to give the best return for effort. 

Agile Manifesto, know the four values and 12 principles. 

4 Values:

  1. individuals and interactions over processes and tools;
  2. working software over comprehensive documentation;
  3. customer collaboration over contract negotiation; and
  4. responding to change over following a plan.

12 Principles:

  1. Satisfying customers through early and continuous delivery of valuable work.
  2. Breaking big work down into smaller tasks that can be completed quickly.
  3. Recognizing that the best work emerges from self-organized teams.
  4. Providing motivated individuals with the environment and support they need and trusting them to get the job done.
  5. Creating processes that promote sustainable efforts.
  6. Maintaining a constant pace for completed work.
  7. Welcoming changing requirements, even late in a project.
  8. Assembling the project team and business owners on a daily basis throughout the project.
  9. Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behavior accordingly.
  10. Measuring progress by the amount of completed work.
  11. Continually seeking excellence.
  12. Harnessing change for a competitive advantage.


SCRUM however, is gaining momentum as the defacto project management framework and should be a tool in your arsenal for SharePoint development.  Agile principles tend to skip some of the more formalized phases of SDLC and I am not suggesting that planning is superfluous; the trick for the technical development team is do not let process get in the way of building your product.

Experience has shown it is likely that you will face significant challenges in trying to implement SCRUM.  The team stakeholders may resist, your organization may resist, and the techniques may not be appropriate.  A simple and practical tip for overcoming these challenges is to try to find someone that can work you through the SCRUM process on suitable projects.  By bringing Agile practices to SharePoint development projects you can aim to reduce time, deliver what the client really needs and make software development more rewarding.  You don’t need to use every facet of a methodology, start with the easier options that will immediately add value.  As your SCRUM team maturity evolves add more pieces. 

Tip:  Microsoft Team Foundation Server (TFS) 2012 has 3 project management templates, one of which is the SCRUM template and this is a good place to start with minimal project management overhead.  The nice thing about TFS 2012 is you can easily amend these templates to suit your needs as your experience grows. 

Traditional approaches such as the SDLC often have a lengthy requirements gathering phase.  This long winded analysis phase is often ingrained into IT folks psyche that people find hard to break away from.  Projects involving a lengthy requirement gathering phase can easily suffer from excessive documentation if there is poor governance.  This documentation can be erroneous, contradictory, outdated, incomplete, challenging to follow and result in documentation overload. 
As a metaphor, SharePoint analysis is like the children’s game “Chinese whispers” or “Telephone” where one person whispers a message to another person, which is passed through a succession of people until the last player announces the message to the entire group.  This lost-in-translation is all too common as excessive noise in documentation or the analysts gloss over the expert’s main point.  Whereas a developer performing analysis generally picks up when something needs detailed explanation as they are “solutioning” the project as they directly communicate with the expert.
The more people in the chain, the more potential for errors in the relayed messages. Moreover, these business processes are often extremely complex, so that the actual intended meaning of the relayed message is lost.  SharePoint is a complex platform and even on the biggest of projects, the success of the technical delivery will often come down to a few key individuals.  Increasing team sizes does not often help and after a certain size becomes a real hindrance.  Agile teams work best when they are relatively small (SCRUM recommends team between 5-9 team members).  If the project is too big, get better quality people; don’t make the commonplace management mistake of adding more resources blindly.

Not all projects or SharePoint teams are ready to work within Agile methods however current commonplace SDLC approaches have problems we hear about repetitively such as change to software cost money and the SDLC is extremely inflexible, Agile based projects lend themself to change. 

Another argument is that that traditional methodologies can be used to give you fixed price quotes.  Vendors operating on a fixed price basis tend to promise the world and try cut every corner to deliver on time (and I hear the vendors screaming already “that is how the other vendors work not us”). 

Nevertheless, many of us realize that software consultancies operate work on the simple maxim ‘sell high, ship quickly’.  Once a software consultancy is in, the inevitable changes that will need to be made will cost the earth.  SCRUM can also run away but with the demonstrable iterations it quick to identify when you are off track and remedy the situation.  Agile methodologies use a time and material model whereas most financial budget decision makers prefer a fixed price (despite this being almost always wrong and they don’t seem to learn).     

Internal software teams often run over in time, deliver the wrong product and buggy solutions due to promises made based on poor initial guestimates.  SDLC can work if managed properly, Agile allows for better feedback controls to verify you are going in the right direction.

SharePoint projects often lend themselves to a ‘time-and-materials’ model as opposed to the ‘fixed-cost’ approach.  If you are unhappy with a project’s development, remove the vendor without the full budget being used up before discovering this project will be successful.  With SCRUM the team have to show you the deliverable product at the end of each sprint (2-4 week delivery phase) and replacing a team members is possible between sprints.

ALM for SharePoint 2013

SharePoint’s developer tooling has matured throughout the iteration of SharePoint.  Tooling is primarily based on Visual Studio and TFS.  ALM covers many roles with the team including project managers, testers, architects and stakeholders.  In this section I mainly focus on ALM for the developer.  Third-party tools assist with building the solution, communication within the team and technical guidance that easily plug into TFS and VS.  An example is CKSDev for Visual Studio.

Tip:  Visual Studio 2012 and TFS 2012 have a large number of purposes.  Always start with the basics of ALM and continue adding the more sophisticated features as your ALM maturity increases.   Source control is definitely the first important feature of TFS.  The next step would be bug tracking.  Build automation is about when you know you are really starting to get going properly with ALM.  With builds your developer isolate code is now integrated into the solution allowing verification of that the individually developed parts fit together.

TFS 2012 comes in 2 on-prem. varieties, don’t bother with the express edition.  It is free but limited to 5 users, if you are this small rather get a hosted TFS 2012 solution or use TFS preview.  TFS has an excellent web user interface portal, which is user friendly for team members that don’t necessarily use Visual Studio to enter Product Backlog Items (PBI’s).  TFS contains the following key components: source control, work items (PBI’s, tasks and bug tracking in SCRUM terminology), build automation and reporting. 

Visual Studio 2012 comes in 4 flavours as a developer you can use the Ultimate, Premium or Professional edition.  Depending on your MSDN subscription use the most feature rich edition you have available.  There is also a Test edition version of Visual Studio 2012 that is not suitable for development.

A good opinion on development machines is that each developer must have a completely standalone environment hosted on visualized PC/laptop infrastructure.  VMware workstation is a good option to provide this virtualized environment to developers.  The chapter in this book on DTAP and automation strongly examines setting up the SharePoint developers’ development environment.  Using automation builds are triggered by developers or are schedules using FSP policy, these builds can include smoke test or full testing scenario allowing for high levels of confidence in that the build work correctly.

Microsoft tooling for SharePoint is good and wide ranging.  Starting with Visual Studio 2012 there are item templates for achieving common tasks.  The community writes many Visual Studio Extensions such as CKSDev.  Consider adding this to the developer machine base builds so when the image is rebuild or the images are distributed the developers are up and running quickly.
Code needs to be in a source code repository such as TFS 2012, using the SCRUM template is the good option.  At the most basic level it allows for easy management of the project using the SCRUM template with the appropriate reports with a source code repository and bug tracking facility.
Assembling all the constituent parts of your SharePoint project using the build functionality available through TFS allows you to have confidence that it all works together and can be deployed into production accurately. 

Build tab within the SCRUM template.
 Build process templates are used for automating the build in TFS.  The figure below shows the default templates.

Built in Build Process Templates
Daily automated builds are a good idea to ensure code is working against your automated tests.

Tip: Don't build your daily automated SharePoint 2013 environment from scratch. Rather use snapshots or cloned images for the base images and merely deploy and test your code through automation.  Chris O’Brien has good information on Continuous Integration for SharePoint check out his blog. 

PowerShell is your friend.  Automate everything in the build.  This allows team members to get the latest code and setup the appropriate databases quickly - the invested time pays for itself almost immediately.  The developers will often use a baseline content database so they know that they have the correct test data.

ALM allows for easy migration onto your Development, Testing, Acceptance and Production (DTAP) environments.  Automated of deployment pieces bring efficient delivery through to the production environment.  I can't stress enough that you need more environments than development and production.  Even the smallest project should have at least three separate environments and remember to keep the production and staging (also referred to as pre-production or acceptance testing) in sync.

Summary

SCRUM is a commonly used Agile framework for delivering projects.  SCRUM lends itself well to a lot of SharePoint projects as it allows for focused collaboration.  Product feedback is on-going and the team demonstrates the project sprints in multiple short iterations to the business which ensures the projects direction is focused.  SharePoint 2013 is a complex product and having smaller teams with superior resources can greatly improve returns. Agile does not mean no documentation, it advocates using a bottom-up self-managing team that is organized.  Agile is not anarchy but allows us to focus on business problems creatively utilizing all team members aiming to work together to manoeuvre SharePoint to meet business needs.  Agile and SCRUM try move away from overdrawn project analysis phases.

Microsoft has a 1st class stack of ALM tools for SCRUM comprising of Visual Studio 2012 and TFS2012 that hook nicely into SharePoint 2013 development projects.  TFS is not just for developers, it can be used by the whole team.  TFS has source control for your code as well as a plethora of features to help your SCRUM based projects such as the SCRUM template, reporting/ project management, requirements and acceptance gathering artifacts, the ability to automate your solution via the build process templates and testing.

Agile for SharePoint (This post)
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1

Thursday 18 August 2011

Building Development Machines

There are 3 schools of thought regardsing development build approaches:
  • Physical (Windows 7 or Windows 2008);
  • VM server hosts i.e. ESXi where the server has multiple VM's and the dev use remote desktop; and
  • VMWare workstation.
VMWare/HyperV are interchangable.
Base physical machine OS will be Windows 7 and run VMWare Workstation
VM needs:
  1. Windows 2008 R2 Std edition x64 – fully patched/updated and include SP1
  2. Add the Active Directory role (ensure ADFS2.0 is installed)
  3. Install Microsoft SQL Server 2008 R2 developer edition x64, install SP1 check using SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition') should be at least 10.50.2500.0
  4. Install SharePoint 2010 enterprise edition, I’d suggest using AutoSPInstaller (with 1 service account as provided by the AD such as demo\administrator), the pre-requistes will enable the appropriate IIS and application server roles for you.
  5. Patch SP2010 to SP1 and also ensure you have the June 2011 CU.
  6. Check SP2010 that a site works using IE.
  7. Install Visual Studio 2010 (appropriate edition – pref ultimate).
  8. Add developer tools such as Office 2010, Fiddler, SPD2010, InfoPath2010, Firefox, CKSDev(VSIX extension)2.1, SharePoint Power tool(vsix extension), U2U, ULSViewer, Beyond Compare, resharper. A comprehensive list is here.
  9. Check source control (TFS2010) works.
  10. Check deployment of code works.
Tip:
Useful to run http://blog.sharepointsite.co.uk/2012/03/turning-on-windows-2008-r2-desktop.html