├── .gitignore ├── LICENSE ├── README.md ├── gettingStarted ├── AdoptionJourney.png ├── AppModelWithGitBranchingDevOps.png ├── AppModelWithGitBranchingDevOpsMultiple.png ├── EnvModelWithUpdateSets.png ├── FAQ.md ├── GitHubFlow_CICD.png ├── Guide.md ├── HybridModel.png ├── README.md └── product_dev_workflow.png ├── links ├── TOIs.md └── enablement.md ├── pluginsAndIntegrations ├── README.md ├── contribute_template.md ├── governance_template.md ├── opensource_kb.md └── support_template.md ├── replaceTeamDev └── README.md └── withDevOps ├── README.md └── Summary.png /.gitignore: -------------------------------------------------------------------------------- 1 | # Compiled source # 2 | ################### 3 | *.com 4 | *.class 5 | *.dll 6 | *.exe 7 | *.o 8 | *.so 9 | 10 | # Packages # 11 | ############ 12 | # it's better to unpack these files and commit the raw source 13 | # git has its own built in compression methods 14 | *.7z 15 | *.dmg 16 | *.gz 17 | *.iso 18 | *.jar 19 | *.rar 20 | *.tar 21 | *.zip 22 | 23 | # Logs and databases # 24 | ###################### 25 | *.log 26 | *.sql 27 | *.sqlite 28 | 29 | # OS generated files # 30 | ###################### 31 | .DS_Store 32 | .DS_Store? 33 | ._* 34 | .Spotlight-V100 35 | .Trashes 36 | ehthumbs.db 37 | Thumbs.db 38 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2020 ServiceNow 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Application Lifecycle Management 2 | This repository is intended as public-facing content for customers, partners, SN developers, SN employees to find updated information on Application Lifecycle Management products. This can include documentation, guides, templates, links, and more. Please feel free to adopt an open-source contribution model to help update or correct any content. 3 | 4 | # Change Log 5 | July 13th, 2022: Updating from "Developer Productivity" to "Application Lifecycle Management" to reflect product and organization scope changes from some time ago now. Repo name was also changed to reflect, GitHub should redirect but some links might require updating. 6 | 7 | # Questions 8 | Send questions to chiarng.lin@servicenow.com 9 | -------------------------------------------------------------------------------- /gettingStarted/AdoptionJourney.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ServiceNow/ALM/aa7495555334d2d55b68963197cc88194234aff5/gettingStarted/AdoptionJourney.png -------------------------------------------------------------------------------- /gettingStarted/AppModelWithGitBranchingDevOps.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ServiceNow/ALM/aa7495555334d2d55b68963197cc88194234aff5/gettingStarted/AppModelWithGitBranchingDevOps.png -------------------------------------------------------------------------------- /gettingStarted/AppModelWithGitBranchingDevOpsMultiple.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ServiceNow/ALM/aa7495555334d2d55b68963197cc88194234aff5/gettingStarted/AppModelWithGitBranchingDevOpsMultiple.png -------------------------------------------------------------------------------- /gettingStarted/EnvModelWithUpdateSets.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ServiceNow/ALM/aa7495555334d2d55b68963197cc88194234aff5/gettingStarted/EnvModelWithUpdateSets.png -------------------------------------------------------------------------------- /gettingStarted/FAQ.md: -------------------------------------------------------------------------------- 1 | Answers to the most common questions we get 2 | =============== 3 | 4 | - [Branching Strategy](#branching-strategy) 5 | - [App Versioning Strategy](#app-versioning-strategy) 6 | - [Using ATF](#using-atf) 7 | - [Using the CI/CD Spoke](#using-the-cicd-spoke) 8 | - [Deployment Model Differences](#deployment-model-differences) 9 | - [Questions to help guide next steps](#questions-to-help-guide-next-steps) 10 | 11 | 12 | Branching Strategy 13 | --------------- 14 | Q. "Is there a best practice or recommendation for how to use branches? For instance, for the simple case that we have discussed, where we have released version 1 and we are working on development of version 2 and supporting bug fixes for version 1, should we have a branch for bug fixing and do development of version 2 in the master branch, have a branch for version 2 and develop bug fixes in the master branch, or have two branches, one for bug fixes to version 1 and one for version 2 development (or something else)? Are there general recommendations like “minimize the number of branches” that we should be aware of?" 15 | 16 | > A. Yes there absolutely are best practices. Start with GitHub flow. Therefore, for this hypothetical case, checkout two branches from master. Merge whichever branch gets past the build/testing into master first. I don't recommend minimizing branch count (why?), but it's a reflection of how many "pieces of work" are ongoing at a time, so you should be trying to get those pieces of work finished and merged into master ASAP anyway. 17 | 18 | Q. "Are there recommendations for releases? For instance, should we always release to production from the master branch?" 19 | 20 | > A. I would recommend starting out with always releasing from master just to make sure your team's process is drilled in. Once you understand why certain feature branches (or railroad track branches) get to parity with master branch after merge, and therefore any apps built from that branch can just be released, then you can start streamlining your workflow. 21 | 22 | Q. "Are there recommendations for merging? For instance, should we merge after every bug fix? This will depend on the answer to #1 and how we handle branching, but is there a general recommendation?" 23 | 24 | > A. It's far easier to merge smaller pieces of work that can pass the CI build with minimal changes to tests, than it is to merge a giant piece of work. So merge early and often. 25 | 26 | Q. "Is there a good way to handle code reviews? Right now we review story-by-story using the update sets for the story to determine what to review. With source control, there will not be separate update sets for each story, so that will not be possible. Is it possible to create a branch for each story and code review that? Should code reviews be done before code is committed or after?" 27 | 28 | > A. This goes back to customers being confused on how to move from Update Sets to using apps, where they need to understand where the abstractions to branching and app versioning come in. In this case, a branch could be a single story, or several stories. As a dev, I should probably be linking the pull request to the story (or stories) that are tied to it. Or commenting in the pull request which stories are included in it. You don't have to do 1 branch for 1 story, that sounds tedious and might not make sense from a functional feature perspective. Code should be committed to a branch first, and a pull request opened, THEN a code review happens. 29 | 30 | App Versioning Strategy 31 | --------------- 32 | 33 | Using ATF 34 | --------------- 35 | 36 | Using the CI/CD Spoke 37 | --------------- 38 | 39 | Q. Would you recommend that we stay on-platform and use the CI/CD Spoke with Flow Designer, or instead start off-platform by learning how to use that our engineering teams use? 40 | 41 | > A. If the customer is just starting out with CI/CD conceptually, and has no experience using tools like GitLab, Jenkins, Azure Pipelines, GitHub Actions, etc., using the spoke with Flow Designer may give them some practice with understanding how to set up an automated testing and deployment pipeline. However, from the perspective of spending the time and effort to build a pipeline and workflow that will last the next 5 or 10 years, we highly recommend that they choose a dedicated CI/CD tool from the ecosystem. 42 | 43 | > A short list of reasons why Flow Designer + CI/CD Spoke isn't a full replacement for a mature CI/CD build automation tool: 44 | > - There isn't a flow trigger for either triggering on pushes to branches or from pull requests in the Git repo an app is linked to Source Control with. 45 | > - Most Git repo products provide the option to automatically merge if the build passes for a pull request, but Flow Designer isn't easily set up for that. You could play around with the GitHub Spoke to get something working with the webhooks, but it's extra work. 46 | > - There are no reusable environment variables in Flow Designer. 47 | > - There isn't a scripted pipeline option for Flow Designer. 48 | > - It's not easy to see a history of pipeline jobs for specific branches in Flow Designer. 49 | > - Hard to define flows based on building from feature branches for testing vs master branch for release. 50 | > - Dedicated tools like Jenkins, GitLab, GitHub Actions, and Azure Pipelines have huge engineering teams behind them driving improvements specifically to address user/customer needs for DevOps workflows. Flow Designer is a generic automation tool for Now Platform. 51 | > - Many products incorporate both a Git repo and pipeline tool together (e.g. Azure DevOps with Repos and Pipelines, GitLab), and have tons of features to make them play well together, given customers plenty of configuration options for their specific needs and workflows. You'll be struggling just to hack something together with Flow Designer and the CI/CD Spoke. 52 | > - At the end of the day, it's hard to create a true CI/CD pipeline that interfaces with branches and pull requests for merging in a standard DevOps model. 53 | 54 | > Please just use tools like GitLab, Jenkins, Azure Pipelines, GitHub Actions, etc. We even provide [nice extensions and template pipeline scripts](https://github.com/ServiceNow/devproductivity-guides/tree/master/pluginsAndIntegrations) for you to get started faster! 55 | 56 | How to migrate from Update Sets to using Apps? 57 | --------------- 58 | 59 | Q. "I’ve had a question recently about how we would support versioning within workflows (and subsequent promotion through the envs) – both from an HR and SecOps perspective. In the example where they want to update an existing HR workflow through an App Repo approach, would this be supported today, or will they need to wait until we support OOTB apps in Quebec? My current understanding is that this use case wouldn’t be available until Quebec but just wanted to confirm with you to make sure I understand this correctly." 60 | 61 | > A. If they've customized the HR or SecOps apps (within the scope of those apps), then they will need to wait until Quebec for the Store/OOTB app support for Source Control and App Repo workflows. 62 | However, if they've been building in their own scoped apps or global (they can add update sets into global apps, for example), those are available as of Paris. 63 | Also, one of the major advantages of moving to using Git and App Repo is the ability to abstract from just moving code (promoting update sets) between environments directly, to being able to compare code between Git branches, and then being able to publish/install/rollback apps to load/unload them into an environment. These are powerful features that help customers to better manage how they develop changes (features, fixes, etc.) and eventually put them in front of their end users in prod. 64 | 65 | Q. "How do I manage multiple developers needing to work on the same app in the same instance, but on separate stories representing different features/fixes with different timelines? Should they all work on the same branch?" 66 | 67 | > A. Let's first review the intended workflow: 68 | > - You have an app. You have a backlog of stories to work on. 69 | > - Multiple devs need to work on their own separate stories at the same time, on that same app. 70 | > - Devs should branch off master to create feature branches for their own work, so they can merge/build/deploy independently. 71 | > - Only one feature branch can be active for an app on a single instance, so this provides incentive for the customer to purchase additional dev instances, so multiple devs can work simultaneously on their own branches, rather than waiting for each other to finish on a single dev instance. 72 | > - Customers are not limited the way SURF is when publishing apps to their app repo. Any app author or dev instance can publish, no need to register just one. 73 | 74 | > General guidelines: 75 | > 1) If all your work must be in a single app, then definitely make use of multiple branches to track different pieces of work (features, fixes, etc.). Pull requests should drive when code reviews and CI builds happen, and therefore which branch needs to be active on an instance in order to publish an application as a version. 76 | > 2) If you have multiple developers working on the same app, then they should use different branches. Ideally, they would also have their own instances so they don't conflict when simultaneously developing. 77 | 78 | > The analogy is performing a maven release. As a dev, assuming my build passed and PR merged, I can switch to the master branch and do a maven release locally. This will produce an artifact I can deploy to prod. Any dev on a team could do this. 79 | > Alternatively, if we have a CD setup, we can also have a dedicated environment in our CD pipeline that does the maven release from master branch once a build has passed and branch is merged. That pipeline could also auto-upload the artifact to Artifactory, and deploy to prod. This would be like having a publishing instance. The advantage here over each dev handling release locally is less work for the dev, and having a standardized release pipeline for the whole team. 80 | 81 | > The feature request I am hearing here is "As a customer, each developer on my team should be able to work on their own separate branches simultaneously on the same app in the same dev instance." The solution that was proposed has been Individual Developer Instances - that is, if you need more branches, then get more instances so you can work simultaneously on multiple branches for the same app. I do recognize the cost barrier to purchasing more instances, and time spent cloning down to many dev instances. Our strategy going forward will be figuring out how to 1) reduce the amount of time it takes to prepare a dev instance from moment of request, and 2) decrease the cost of an instance by either decreasing the disk usage or by decreasing the time the instance needs to live. I also understand that customers are coming from Update Sets, where multiple devs in the same instance can each be in their own Update Set and not conflict with each other while working on their own separate stories. Customers will need to be educated on the benefits of moving from a model where code just lives in an environment and changes are packed and moved as Update Sets, to one where code is packed into apps and versioned accordingly, and changes are managed via Git branches and pull requests are used to review and check for conflicts on merge. 82 | 83 | Deployment Model Differences 84 | --------------- 85 | 86 | The behavior or state of applications as being "deployed" to instances differs between Update Sets, App Repo installs, versus Source Control. App Repo is just the artifact store that handles the app zips as they get published/installed between instances. 87 | 88 | Some helpful documentation topics that we published recently to clarify these behaviors: 89 | - https://docs.servicenow.com/bundle/rome-application-development/page/build/applications/concept/tips-production-deployment.html 90 | - https://docs.servicenow.com/bundle/rome-application-development/page/build/applications/concept/tips-customer-updates.html 91 | - https://docs.servicenow.com/bundle/rome-application-development/page/build/applications/reference/generation-skip-records-app-installs.html 92 | - https://community.servicenow.com/community?id=community_blog&sys_id=ef21c1d21bf04c507a5933f2cd4bcb34 93 | 94 | In short, applications that are "in development" live in the `sys_app` table, and this is where both Update Sets and Source Control expect apps to be. 95 | Applications that are being deployed to another instance from the App Repo will live in the `sys_store_app` table. 96 | Transitioning from one model to the other on an instance for a given app does require conversion, which we're working towards providing features for (rather than relying on the support org workflow). 97 | 98 | Q: Incompatible with apps previously deployed via Update Set 99 | > - With App Repo based deployment, applications have two types of instances that interface with it - app-author instances where development is done, versus app-client instances where the app is installed from the App Repo. In the former case, the app lives in the `sys_app` table, whereas in the latter, the `sys_store_app` table. This is to distinguish between the two types of instances. 100 | > - We are providing a feature in San Diego to convert applications from `sys_app` to `sys_store_app` table, therefore enabling customers to self-serve and choose whether a particular instance is meant to be an app-author or app-client instance for a given application. 101 | 102 | Q: Inability to force deploy over local instance artifacts instead of skipping 103 | > - This is by design, because otherwise local changes would get overwritten, perhaps unintentionally, on application installs from App Repo. We would not recommend continuing to do development work on app-client instances where applications are being installed to. If there are local hotfixes the customer wishes to blow away during app installs, deleting from the sys_update_xml table, then installing the app, should overwrite it. 104 | 105 | Q: Lock out of app after PROD clone to DEV 106 | > - If the `sys_app` record exists on the target (DEV) instance for a clone operation, we have logic that handles conversion of the app from the `sys_store_app` table to the `sys_app` table properly so development can continue. 107 | > - If the `sys_app` record doesn't exist on the target (e.g. another DEV2 instance) instance for a clone operation, the app will continue existing on `sys_store_app` table, where it lives in Prod. For app development on that DEV2 instance to be enabled, either the app will need to be pulled from Source Control or will need to have a one-time conversion completed via the San Diego feature. 108 | 109 | Q: Unable to restore GIT repo version over cloned `sys_store_app` copies 110 | > - This is also by design, because app-client instances aren't intended to be used for development for that given app. 111 | > - We'll take a feature request to provide self-serve options for customers to transition an app from `sys_store_app` to `sys_app` (opposite direction from SD feature), so that they can set up an instance more flexibly. 112 | 113 | Q: No easy way for us to self-convert app from `sys_store_app` to `sys_app` for additional development after clone 114 | > - See 3b and 4b. 115 | Q: Cap on max number of versions stored in App Repo 116 | > - Correct, the current maximum number of versions for a given app in App Repo is 20, and cannot be configured by customers. We are looking into how to provide more configurability by separating the App Repo functionality from the Store. 117 | 118 | Q: Cap on max number of artifacts allowed in an application. A few of our apps are too big to live in the Repo as a single app 119 | > - Similar to 6b, there are constraints with the existing App Repo that we need to open up configuration for by decoupling App Repo (customer/partner development use cases) from the Store (partner and SN publishing use cases). 120 | 121 | Q: Undesirable sys_metadata_delete removal of destination instance artifacts after local instance recreation of those artifacts 122 | > - See above articles on author elective delete properties. We're taking note that these configurations are not intuitive for customers to understand how to set up to achieve their desired deletion behaviors. 123 | > - This also applies to the sys_choice issues mentioned in the support cases. 124 | > - Separately, I noted there's another case on Dictionary Entry issues. Dictionary Entry is a column. Therefore, if there's data in it (e.g. in Prod), we won't delete it. The workflow would be to delete the data in that column in Prod, then attempt an install from the app. The rationale for this is so that customers don't accidentally delete data unintentionally. 125 | 126 | Q: Inability to convert our release operations to follow one standard best practice because they will need to support Update Set deployments simultaneously with App Repo deployments 127 | > - For a given application, customers should choose one model for deployment onto an instance, rather than attempt to mix Update Sets, Source Control, and App Repo installs. 128 | > - However, different applications can have a mix of models. For example, if the HR or CSM customizing development squad isn't ready to adopt app-driven workflows yet (e.g. on Paris rather than Q or R), their customizations can continue to be migrated via Update Sets. Meanwhile, other scoped app or global app teams can adopt app-based development. 129 | > - Most customers aim for a vision of onboarding all teams and apps to the same, unified, development/pipeline model at some point. This is a multi-stage journey. 130 | 131 | ![Scaling Deployment Pipelines](/gettingStarted/AdoptionJourney.png) 132 | 133 | Questions to help guide next steps 134 | --------------- 135 | 136 | 1. Have they adopted Source Control yet? Are they familiar with using Git branches or doing pull requests to merge into master? For example, a branching strategy like [GitHub flow](https://guides.github.com/introduction/flow/) as a starting point. 137 | 2. Have they had a chance to check out our [Paris release features](https://developer.servicenow.com/blog.do?p=/post/paris-source-control/) yet? Specifically, supporting global apps with Source Control, and delta-loading. 138 | 3. How familiar are they with build automation tools like Azure Pipelines or Jenkins? Do they already have a preference? Alternatively, they can also get started on-platform with Flow Designer and subflows using the [CI/CD Spoke](https://docs.servicenow.com/bundle/orlando-servicenow-platform/page/administer/integrationhub-store-spokes/concept/cicd-spoke.html) to get a quick and simple pipeline running. 139 | 4. Are they using [ATF for automating testing](https://docs.servicenow.com/bundle/paris-application-development/page/administer/auto-test-framework/concept/automated-test-framework.html) as a part of today's workflows? It's one of the bigger benefits of adopting CI. 140 | -------------------------------------------------------------------------------- /gettingStarted/GitHubFlow_CICD.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ServiceNow/ALM/aa7495555334d2d55b68963197cc88194234aff5/gettingStarted/GitHubFlow_CICD.png -------------------------------------------------------------------------------- /gettingStarted/Guide.md: -------------------------------------------------------------------------------- 1 | # I am not done with this! 2 | 3 | 4 | **What processes and tools to choose for developing with Source Control and CI/CD on ServiceNow?** 5 | 6 | The purpose of this article is to clarify: 7 | 8 | - Where do I get started if I don't know? 9 | - What are the recommended best practices for a DevOps-driven development process? 10 | - What are the tradeoffs when making tooling decisions? 11 | 12 | This article assumes an understanding of: 13 | 14 | - The purpose of DevOps in driving quality of applications and delivery velocity for the organization. 15 | - Familiarity with common DevOps ecosystem tools, such as Jenkins, Azure DevOps, GitHub, GitLab, etc. 16 | - Familiarity with ServiceNow capabilities and development of apps using Studio. 17 | 18 | Summary of Product + Development Process: 19 | 20 | ![](https://github.com/ServiceNow/devproductivity-docs/blob/master/gettingStarted/product_dev_workflow.png) 21 | 22 | What happens in Discovery? 23 | 24 | - This is how your team identifies the needs of your users. For example, how do you handle intake of feature requests, bugs, new application requests, etc. Are users successful at using what you built? Is your roadmap heading in the right direction? 25 | - Common patterns for handling intake 26 | - Talk directly to your users 27 | - Ticketing system 28 | - Feature upvote system 29 | - Community forums/channels 30 | - Tooling choices 31 | - If your priority is to link intake request tickets to stories on a backlog, you may consider using the same tool, i.e. ServiceNow ITSM with the Agile Development 2.0 product. 32 | - If your priority is to share the same engineering backlog tool between the company, so all development teams share the same structure for handling projects, linking stories between backlogs for dependencies, you may consider using a common backlog tool (e.g. ServiceNow Agile Development 2.0, Azure Boards, Jira, Trello, etc.) 33 | - But at the end of intake, it's important to document user stories in your agile backlog of choice, so they are ready to be prioritized and planned for work in sprints. This leads to our next section, Planning. 34 | 35 | What happens in Planning? 36 | 37 | - This is how the intake of needs turn into features on a prioritized backlog of stories (or a roadmap). This is also where you align stakeholders and users on prioritization of your backlog. You may start breaking down user stories into designs and engineering stories. 38 | - Common patterns for handling planning (alignment on prioritization) 39 | - Understand your users' needs and objectives 40 | - Clearly defined goals and metrics (how you're measuring success towards goals) 41 | - Roadmap (or backlog) in prioritized rank order in a deck or backlog tool of choice 42 | - Measure outcomes on what you're building and how it's being used to feed back into future prioritization 43 | - Some organizations also choose to do UI design work at this stage, so you may find working with UI/UX designers on tools like Balsamiq, Sketch, Invision, or Miro easier to show mockups of workflows and views. 44 | - Tooling choices 45 | - Typically, an agile backlog tool that can show a roadmap-level view of priorities. Alternatively, simple slides reflecting the same. 46 | - At the end of planning, you should have alignment with your stakeholders/users on the prioritization of your roadmap, and you're ready to break down into epics and stories on an engineering backlog. 47 | 48 | What happens in Execution? 49 | 50 | - Once you have validated that you're solving for a real user need and prioritizing building the right things, then it's time to turn into engineering stories to execute from. Generally, features from roadmaps are translated into epic on engineering backlogs, then broken down into engineering stories to be estimated and prioritized into sprints. Once a story is in a sprint, an engineer can pick up that story and begin working on the feature, which will generally go through the code, build/test, release/deploy workflow. 51 | - Epics and Stories 52 | - Once prioritization of your roadmap has been aligned with stakeholders, you're ready to break down the near-term features into epics and stories on your engineering backlog. These stories are intended to capture the work that will be done and should reflect what the feature will end up looking and working like. 53 | - Common patterns for breaking down into epics and stories 54 | - Firstly, make sure you have mockups and workflow diagrams clearly documented so the team has something to refer to when turning features into epics and stories. 55 | - 56 | - Tooling choices 57 | - Backlog: 58 | - Code 59 | - Fairly self-explanatory, the goal here is to manage your code changes with a larger team such that it's easy for the team to work on separate features while providing code review coverage for each other. 60 | - Common patterns for coding best practices 61 | - Source-driven development with branching workflows. We recommend that your team use a Git repo to manage your code, and separate branches representing a developer working on a separate feature or story from your engineering backlog. 62 | - Stories can then be linked to a branch or a pull request, depending on the model you prefer for managing and seeing changes. 63 | - General workflow for a developer: 64 | - Start from master branch, which is the current build of the application in production. 65 | - On your development environment, create a branch from master, representing changes you are making for a story or feature. 66 | - Make sure to commit your changes as you are developing, it helps to keep track of the changes you are making. In dev Studio, when using Source Control, committing also pushes your code to the linked remote Git repo. 67 | - Once you are ready, you can create a pull request in your Git repo product (e.g. GitHub, Azure Repos), which compares the changes between the two branches in preparation for a merge. You should do a code review in your team at this point. 68 | - You can then set up your Git repo such that on pull request, a CI build is kicked off to determine whether the branch passes all of the unit/integration/functional tests and reports back to the pull request whether the build had a success or failure outcome. This, in conjunction with the code review, should determine whether your team should go ahead with the code merge, or have the developer go back and make changes on their dev branch. 69 | - Once your pull request has passed code review and the CI build, you can safely merge to master and then determine whether to release the master branch as a build of the application. 70 | 71 | - Need a section on rebasing when there's distributed development happening on multiple branches, perhaps on multiple instances. 72 | - Need a section on reverting commits. 73 | 74 | - Tooling choices 75 | - For developing on ServiceNow, it's best to use either the [built-in Studio product](https://docs.servicenow.com/bundle/orlando-application-development/page/build/applications/concept/c_ServiceNowStudio.html), or [VS Code](https://code.visualstudio.com/)[with our extension](https://marketplace.visualstudio.com/items?itemName=ServiceNow.now-vscode) for scripting. You may find it difficult to interpret the XML files in the directories for our app if using another IDE. 76 | - For source control, as long as it's a Git repo, our Source Control features will work with any of them. For example, GitHub, GitLab, Azure Repos, just to name a few. Our recommendation would be to stick with what the rest of your organization is using, so it's easier to organize code collaboration workflows when doing code reviews, integrating webhooks into build servers, etc. 77 | - Build/Test 78 | - Continuous integration is intended to help you validate whether a dev branch should be merged into your master branch as a part of a pull request. This also means that ideally, your build servers should be able to kick off their own set of test environments, specific to that particular CI build each time. That way, multiple developers can each submit their own PRs for their own dev branches, and aren't blocked on running the CI build while waiting for another developer's branch to finish testing. 79 | - Common patterns for Continuous Integration build/test best practices 80 | - Automated Tests 81 | - Smoke 82 | - This is a small suite of tests that lets you know early whether the rest of the CI build is worth running, and helps you to save time if there are critical errors/bugs in the branch being tested. 83 | - Unit 84 | - These are tests intended to test whether an individual method or class works by itself. In the ServiceNow world, you may extend this to whether a particular table or field works the way as intended. 85 | - Integration 86 | - These are tests where you start combining functionality to make sure they work together. For example, perhaps you have data from one application and workflow being completed in another one, you should have a test that covers the complete end-to-end workflow. 87 | - Functional 88 | - Functional tests are sometimes extensions of integration tests, but focus primarily on the click-and-scroll part of the experience. Sometimes also known as UI testing. 89 | - Acceptance 90 | - This is where your product manager, product owner, or team tries out the features in a staging environment to make sure it works as intended, and meets the acceptance criteria you defined for the story. 91 | - Reporting build results 92 | - Build tools generally have their own UI for showing the results of builds as pass or fail, and which specific tests failed. This is the detailed level view your team will need to rely on to figure out what to fix. 93 | - You can also report the build result directly into the PR so it's easier to track the "progression" of a dev branch. This can be accomplished via webhooks (e.g. GitHub to Jenkins), or just via the platform capabilities (e.g. Azure DevOps products). 94 | - You can also choose to report the build result to another third party tool to aggregate in one place, for example ServiceNow Enterprise DevOps product. 95 | - Tooling choices 96 | - API vs Spoke. 97 | - ServiceNow offers to a two-pronged strategy when it comes to choosing setting your CI/CD build. 98 | - Firstly, if you're experienced in DevOps, and already have your favorite set of 3rd party ecosystem tools to bring with you, we provide generic API endpoints to integrate with so you can automate deployment of your Now Platform applications, running ATF test suites, etc. 99 | - However, if you don't have any experience using 3rd party tools such as Azure, Jenkins, GitLab, etc., we also want to make it easy for you to get started by providing capabilities to build rudimentary CI/CD workflows with Flow Designer, via subflows published with the CI/CD Spoke on the IntegrationHub store. 100 | - Lastly, as part of our strategy to make it faster to get started regardless of which bucket your team falls into, we will be providing extensions and plugins published on the most popular marketplaces, so customers can get started with CI/CD builds faster using pre-built templates and "steps". 101 | - Build server. 102 | - Build servers and pipeline automation tooling allow you to define a CI or CD build, when to trigger it, and have it automated to increase your team's delivery velocity. 103 | - Common choices include Jenkins, Azure Pipelines, GitLab, to name a few. Your team should choose the tool that the rest of your company is using, so share the knowledge and configurations where possible. 104 | - Code repository. 105 | - Application repository. 106 | - Test environments and setup. 107 | - Test framework. 108 | - On ServiceNow, Automated Test Framework is the recommended starting point for setting up your tests and test suites for automated test coverage. You will want to run this in a subprod environment specific to use as a test environment. 109 | - 110 | - Source control for tests. 111 | - Release/Deploy 112 | - Continuous delivery is intended to 113 | - Common patterns for Continuous Delivery release/deploy best practices 114 | - Application versioning 115 | - Production deployment 116 | - Change management 117 | - Updating stories 118 | - Tooling choices 119 | - API vs Spoke. 120 | - There's a number of continuous delivery tools that can help you automatically manage release versioning, different strategies for rolling deployments. This author is not very familiar with this piece, so won't be too prescriptive. 121 | -------------------------------------------------------------------------------- /gettingStarted/HybridModel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ServiceNow/ALM/aa7495555334d2d55b68963197cc88194234aff5/gettingStarted/HybridModel.png -------------------------------------------------------------------------------- /gettingStarted/README.md: -------------------------------------------------------------------------------- 1 | ## Demo Videos on Youtube 2 | 3 | - [ServiceNow Studio Source Control Demo for Merge Conflict](https://www.youtube.com/watch?v=I7497g9XPTY) Watch how Peter and Rachel can work on separate features on different feature branches, then use GitHub's features to resolve conflicts prior to merging in a Pull Request. 4 | -------------------------------------------------------------------------------- /gettingStarted/product_dev_workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ServiceNow/ALM/aa7495555334d2d55b68963197cc88194234aff5/gettingStarted/product_dev_workflow.png -------------------------------------------------------------------------------- /links/TOIs.md: -------------------------------------------------------------------------------- 1 | # Transfer of Information (TOI) links 2 | TOI links are primarily intended for SN support engineering and SI partners to deep dive into how features are intended to work and how they were implemented, to better assist customer troubleshooting and enablement. 3 | Links might only be accessible to those audiences. 4 | Content will be organized by product area. 5 | 6 | # Table of Contents 7 | 1. [Application Authoring and Deployment](#AuthorDeploy) 8 | 2. [Application Storage](#Storage) 9 | 3. [Application Packaging and Install Engine](#Packaging) 10 | 4. [Automated Test Framework (ATF)](#ATF) 11 | 5. [Upgrades](#Upgrades) 12 | 6. [Instance Automation](#Instance) 13 | 7. [Off-Platform Development Tooling](#Tooling) 14 | 15 | ## Application Authoring and Deployment 16 | This includes features such as Source Control, CI/CD APIs and Spoke, Update Sets to App migration features, scripting, etc. 17 | | Release|Links| 18 | | -----------|-----------| 19 | | Tokyo|[Reduced noise in commits in Source Control
Application Operation Queue for CI/CD
Self-serve conversion for Store to Development mode](https://trainingops.servicenow.com/detail/videos/platform_________/video/6307381624112/tokyo:-platform---source-control-and-app-install-enhancements?page=1)
["ECMASscript 2021" JavaScript update](https://trainingops.servicenow.com/detail/video/6307740530112/tokyo:-platform:-platform-logic---ecmascript-2021-javascript-update?q=ecmascript)| 20 | | San Diego|[Application Install Optimizations using diffs](https://trainingops.servicenow.com/detail/video/6291005424001/san-diego:-platform:-dev-at-scale---app-install-optimization?q=dev%20at%20scale)
[Self-serve conversion for Development to Store mode
Bulk add global files from Update Sets to Global Apps
CI/CD API for Source Control Import using existing credentials
Source Control stashing improvements](https://trainingops.servicenow.com/detail/video/6291007607001/san-diego:-platform:-dev-at-scale---application-lifecycle-engine-enhancements?q=dev%20at%20scale)| 21 | | Rome|[Selective commits for untracked changes](https://trainingops.servicenow.com/detail/video/6258844692001/rome:-platform---selective-commits-for-untracked-changes?page=3&q=rome%20platform)
[Source Control default email for commits](https://trainingops.servicenow.com/detail/video/6258845288001/rome:-platform---default-email-for-commits?page=3&q=rome%20platform)
[Import update set history as commits on initial link to Source Control](https://trainingops.servicenow.com/detail/video/6258845185001/rome:-platform---import-update-set-history-as-commits?page=3&q=rome%20platform)| 22 | | Quebec|[Application Customizations for Store Apps](https://trainingops.servicenow.com/detail/video/6208831608001/quebec:-platform---source-control---application-customizations?q=source%20control)
[Batch Install with CI/CD API and Spoke](https://trainingops.servicenow.com/detail/video/6208819597001/quebec:-platform---ci-cd-api---batch-install-and-spoke-updates?q=batch%20install)| 23 | | Paris|[Global application support for Source Control and App Repo
Source Control Apply Remote Changes with delta-loading](https://trainingops.servicenow.com/detail/video/6161217575001/paris:-platform---source-control-integration---global-source-support-in-source-control-and-delta-loading?q=source%20control)| 24 | | Orlando|[Source Control for behind-firewall Git repos using MID Server
Selective Commits
Collision Avoidance
Branching and merging with Git](https://trainingops.servicenow.com/detail/video/6102987529001/orlando:-platform-eng:-source-control---dev-scale?q=source%20control)| 25 | 26 | ## Application Storage 27 | This includes products such as the Application Repository, whether hosted on the Store or the self-hosted varietal. 28 | | Release|Features and Links| 29 | | -----------|-----------| 30 | | San Diego|[Self-Hosted Application Repository (SHAR)](https://trainingops.servicenow.com/detail/video/6291005321001/san-diego:-platform:-self-hosted-application-repository?q=self-hosted) [(Store App)](https://store.servicenow.com/sn_appstore_store.do#!/store/application/a8a6a9135f02301011d57104c173138d)| 31 | 32 | ## Application Packaging and Install Engine 33 | This will include features that expand the Application model. 34 | | Release|Features and Links| 35 | | -----------|-----------| 36 | | Rome|[Hosted plugins](https://trainingops.servicenow.com/detail/video/6255952905001/rome:-platform---hosted-plugins?page=6&q=rome%20platform)
[Application and Plugin installation changes](https://trainingops.servicenow.com/detail/video/6255957405001/rome:-platform---app-plugin-installation-changes?page=6&q=rome%20platform)| 37 | 38 | ## Automated Test Framework (ATF) 39 | This includes features for handling test automation and validation for either Upgrade use cases or application development in CI/CD pipelines. 40 | | Release|Features and Links| 41 | | -----------|-----------| 42 | | Tokyo|[Test Generator and Cloud Runner](https://trainingops.servicenow.com/detail/video/6310010259112/tokyo:-platform---atf-test-generator-and-cloud-runner?q=test)| 43 | | San Diego|[Breakpoints and pausing before rollback](https://trainingops.servicenow.com/detail/video/6280498946001/san-diego:-platform---automated-test-framework-breakpoints?q=breakpoint)
[Run Server Side Script Enhancements](https://trainingops.servicenow.com/detail/videos/platform_______/video/6280500141001/san-diego:-platform---automated-test-framework---run-server-side-script-enhancements)| 44 | | Rome|[Headless Browser with Docker](https://trainingops.servicenow.com/detail/video/6256327502001/rome:-platform---headless-browsers?q=headless) [(Docker Image)](https://github.com/ServiceNow/atf-headless-runner)
[Click a modal button enhancements](https://trainingops.servicenow.com/detail/video/6256328750001/rome:-platform---click-a-modal-button-enhancements?page=5&q=rome%20platform)
[Screenshot improvements](https://trainingops.servicenow.com/detail/video/6256328650001/rome:-platform---screenshot-improvements?page=5&q=rome%20platform)
[Select2 library support](https://trainingops.servicenow.com/detail/video/6256327696001/rome:-platform---select-2-support?page=6&q=rome%20platform)
[Assert text on Page enhancements](https://trainingops.servicenow.com/detail/video/6256328434001/rome:-platform---assert-text-on-page-enhancements?page=6&q=rome%20platform)
[Component finder enhancements](https://trainingops.servicenow.com/detail/video/6256328494001/rome:-platform---component-finder-enhancements?page=6&q=rome%20platform)| 45 | | Quebec|[Custom UI Support and Reference Pickers](https://trainingops.servicenow.com/detail/videos/platform___/video/6210490390001/quebec:-platform---automated-test-framework---custom-ui-support-and-reference-pickers?autoStart=true)
[Custom UI Support for (page) Developer-specified Identifiers](https://trainingops.servicenow.com/detail/videos/platform___/video/6210492159001/quebec:-platform---automated-test-framework---custom-ui-support-of-page-developer-specified-identifiers?autoStart=true)
[Support for testing GlideModalForms](https://trainingops.servicenow.com/detail/videos/platform___/video/6210492160001/quebec:-platform---automated-test-framework---support-of-testing-glidemodalforms?autoStart=true)| 46 | | Paris|[Custom UI Versioning Support](https://trainingops.servicenow.com/detail/videos/platform__/video/6161217234001/paris:-platform---atf---custom-ui-versioning-support?autoStart=true)
[Custom UI Improved Indexing](https://trainingops.servicenow.com/detail/videos/platform__/video/6161217118001/paris:-platform---atf---improved-indexing?autoStart=true)
[Page Inspector Enhancements](https://trainingops.servicenow.com/detail/videos/platform__/video/6161215369001/paris:-platform---atf---page-inspector-enhancements?autoStart=true)| 47 | | Orlando|[List and Related Lists](https://trainingops.servicenow.com/detail/video/6101195268001/orlando:-platform-eng:-atf---list-and-related-list-support?autoStart=true&q=related%20list)
[Forms in Workspace](https://trainingops.servicenow.com/detail/videos/platform-eng_/video/6101204067001/orlando:-platform-eng:-atf---forms-in-workspaces-testing-support)
[Custom UI: UI Formatter support](https://trainingops.servicenow.com/detail/videos/platform-eng_/video/6101247632001/orlando:-platform-eng:-atf---ui-formatter-testing-support)| 48 | | New York|[Parallel Testing for Test Suites](https://trainingops.servicenow.com/detail/videos/platform-eng/video/6049737607001/new-york:-platform-eng:-explorer---automated-test-framework?autoStart=true)| 49 | | Madrid|[Custom UI Support
Parameterized Testing
Quick Start Tests engine](https://trainingops.servicenow.com/detail/video/5971822044001/madrid:-platform:-platform-atf-tests?autoStart=true&q=atf%3A)| 50 | 51 | ## Upgrades 52 | This includes both features for improving visibility of Upgrade operations in the Upgrade Center, as well as underlying Upgrade Engine enhancements. 53 | | Release|Features and Links| 54 | | -----------|-----------| 55 | | Tokyo|[Upgrade Plans](https://trainingops.servicenow.com/detail/video/6307540280112/tokyo:-platform:-platform-dev---platform-evolution---upgrade-plans?q=tokyo%20upgrade%20plans)
[Plugin loading changes for node restart enhancements](https://trainingops.servicenow.com/detail/video/6307543244112/tokyo:-platform:-platform-dev---platform-evolution---plugin-loading-changes-for-node-restart-enhancements?q=tokyo%20node%20restart)| 56 | | San Diego|[Upgrade Engine Changes](https://trainingops.servicenow.com/detail/video/6280499660001/san-diego:-platform---upgrade-engine-changes?q=san%20diego%20upgrade%20engine)| 57 | | Rome|[Upgrade Center Enhancements](https://trainingops.servicenow.com/detail/video/6255952906001/rome:-platform---upgrade-center-enhancements?page=6&q=rome%20platform)
[Upgrade Preview Changes](https://trainingops.servicenow.com/detail/video/6255960620001/rome:-platform---preview-changes?page=6&q=rome%20platform)
[FIPS-IL5 Revise use of MD5](https://trainingops.servicenow.com/detail/video/6255954488001/rome:-platform---fips-il5:-revise-use-of-md5?q=fips%20revise)| 58 | | Quebec|[Upgrade Engine: Fix Script Enhancements](https://trainingops.servicenow.com/detail/video/6210161883001/quebec:-platform---upgrade-engine-optimizations---fix-script-enhancements?page=1&q=upgrades)
[Upgrade Engine: Database Upgrade Log Extraction](https://trainingops.servicenow.com/detail/video/6210159322001/quebec:-platform---upgrade-engine-optimizations---database-upgrade-log-extraction?page=1&q=upgrades)
[Upgrade Engine: Upgrade Center](https://trainingops.servicenow.com/detail/video/6210158101001/quebec:-platform---upgrade-engine-optimizations---upgrade-center?page=1&q=upgrades)
[Upgrade Engine: Upgrade Speed Optimizations](https://trainingops.servicenow.com/detail/video/6210151036001/quebec:-platform---upgrade-engine-optimizations---upgrade-speed-optimizations?page=1&q=upgrades)| 59 | | Paris|[Java upgrade engine changes
Java zboot engine changes](https://trainingops.servicenow.com/detail/video/6162275696001/paris:-platform---platform-backend---java-upgrade-engine?page=1&q=upgrades)
[Upgrade Preview](https://trainingops.servicenow.com/detail/video/6162145103001/paris:-platform---upgrade-center---upgrade-preview?page=1&q=upgrades)
[Upgrade Preview - Monitor, Summary, and VTB](https://trainingops.servicenow.com/detail/video/6162145673001/paris:-platform---upgrade-center---upgrade-preview---monitor-summary-and-vtb?page=1&q=upgrades)
[Upgrade Center: Upgrade Preview Overview](https://trainingops.servicenow.com/detail/video/6162145673001/paris:-platform---upgrade-center---upgrade-preview---monitor-summary-and-vtb?page=1&q=upgrades)| 60 | | Orlando|None| 61 | | New York|[Upgrade Engine and Monitor](https://trainingops.servicenow.com/detail/video/6049988688001/new-york:-platform-eng:-upgrade-engine-and-monitor?page=2&q=upgrades)| 62 | 63 | ## Instance Automation 64 | This will include products that provide easier provisioning and management of instances, in particular towards a DevOps model. 65 | | Release|Features and Links| 66 | | -----------|-----------| 67 | | Quebec|Innovation Labs: Clone Management Console [(Store App)](https://store.servicenow.com/sn_appstore_store.do#!/store/application/f07d8dd73bb01010aaec0896c3efc452)| 68 | 69 | ## Off-Platform Development Tooling 70 | This includes products that enable integration and automation with ServiceNow instances, such as the CLIs and External CI/CD Integrations. 71 | | Release|Features and Links| 72 | | -----------|-----------| 73 | | Quebec|[ServiceNow CLI](https://trainingops.servicenow.com/detail/video/6246068680001/technical-support:-servicenow-store:-platform---servicenow-cli-metadata-v1.0-v1.1-april-2021?q=cli) [(Store Clients)](https://store.servicenow.com/sn_appstore_store.do#!/store/application/9085854adbb52810122156a8dc961910/1.1.0) [(Store Metadata App)](https://store.servicenow.com/sn_appstore_store.do#!/store/application/5be94e20c3cb1010e44fe317a840dd15/1.1.2)
[External CI/CD Integrations](https://github.com/ServiceNow/ALM/tree/master/pluginsAndIntegrations)| 74 | -------------------------------------------------------------------------------- /links/enablement.md: -------------------------------------------------------------------------------- 1 | ## CreatorCon / Knowledge Session 2 | 3 | K22: Application Lifecycle Management And You 4 | 5 | - https://knowledge.servicenow.com/lasvegas/sessiondetail?sessionId=1649880318349001pA7W&sessionTimeId=1649970998977001EUTe&state=k22lasvegas.sessiondetail&redirect_uri=https%3A%2F%2Fknowledge.servicenow.com%2Flibrary 6 | 7 | K21: Setting up a pipeline using CI/CD APIs (GitHub example) 8 | 9 | - https://nowlearning.servicenow.com/lxp?id=learning_course_prev&course_id=189a789a1b3fe010a5e699b1b24bcbac 10 | 11 | CC20: Building CI/CD pipelines for your Now Platform apps on Azure DevOps 12 | 13 | - https://events.servicenow.com/widget/servicenow/creatorcon2020/creatorconschedule/session/1601571966226001aL9U#1602085423551001RF9p 14 | 15 | ## TechNow Episodes 16 | 17 | TechNow Ep 87 | Exploring ServiceNow DevOps 18 | 19 | - https://community.servicenow.com/community?id=community_blog&sys_id=1e3ce262db18bc9092bb0b55ca961923 20 | - https://www.youtube.com/watch?v=uMIF04VFn_Y&feature=emb_logo 21 | 22 | ## Break Point Podcasts 23 | 24 | San Diego Dev Features with Chiarng Lin 25 | 26 | - https://podcasts.apple.com/us/podcast/san-diego-dev-features-with-chiarng-lin/id1453762712?i=1000553406074 27 | 28 | ECMAScript 2021 with Paul Jensen 29 | 30 | - https://podcasts.apple.com/us/podcast/ecmascript-2021-with-paul-jensen/id1526244528?i=1000577179233 31 | 32 | Command Line Interface with Chiarng Lin 33 | 34 | - https://podcasts.apple.com/us/podcast/command-line-interface-with-chiarng-lin/id1526244528?i=1000511385485 35 | 36 | ## Creator Toolbox 37 | 38 | Upgrade Plans - Creator Toolbox 2022-08-30 39 | 40 | - https://www.youtube.com/watch?v=9_vo5M46dSM 41 | 42 | What's new with managing app dev in San Diego - Creator Toolbox 2022-03-08 43 | 44 | - https://www.youtube.com/watch?v=M0CDoF5zaEk 45 | 46 | ## Developer Blog Posts 47 | 48 | AUTOMATE YOUR CI/CD PIPELINE USING GITHUB ACTIONS 49 | 50 | - https://developer.servicenow.com/blog.do?p=/post/cicd-pipeline-github-actions/ 51 | 52 | GLOBAL APP SOURCE CONTROL - NEW IN PARIS 53 | 54 | - https://developer.servicenow.com/blog.do?p=/post/paris-source-control/ 55 | 56 | HOW TO BACKUP YOUR PERSONAL DEVELOPER INSTANCE (PDI) 57 | 58 | - https://developer.servicenow.com/blog.do?p=/post/backup-your-pdi/ 59 | 60 | ## Community Blog Posts 61 | 62 | CI: Promoting ServiceNow code using Azure DevOps pipelines Pt1 63 | 64 | - https://community.servicenow.com/community?id=community_blog&sys_id=d1c1dbd7db2451500d48db85ca9619e7 65 | 66 | CI: Promoting ServiceNow code using Azure DevOps pipelines Pt1.5 67 | 68 | - https://community.servicenow.com/community?id=community_blog&sys_id=52b6a1cadb199590b3c099ead396194 69 | 70 | Platform Foundation Academy - Past and Future Sessions 71 | 72 | - https://community.servicenow.com/community?id=community_blog&sys_id=b3d60bc5db0d3410414eeeb5ca96190a 73 | 74 | ## ServiceNow Support 75 | 76 | Automated Test Framework | Overview 77 | 78 | - https://www.youtube.com/watch?v=bhFV4QIUufo 79 | 80 | Getting Started with the Automated Test Framework 81 | 82 | - https://www.youtube.com/watch?v=Mq9ArDiDC2U 83 | 84 | Automated Test Framework | Pro tips, helpful features, and test storage recommendations 85 | 86 | - https://www.youtube.com/watch?v=rVj0aQymN38 87 | 88 | ## Old Dev@Scale Content 89 | 90 | Documentation 91 | 92 | For documentation on the APIs underlying the build steps provided by the various extensions/plugins/Actions. 93 | - https://developer.servicenow.com/dev.do#!/reference/api/sandiego/rest/cicd-api 94 | 95 | You may also find the Source Control learning plan helpful as a starting point.  96 | - https://developer.servicenow.com/dev.do#!/learn/learning-plans/sandiego/new_to_servicenow/app_store_learnv2_devenvironment_sandiego_source_control_objectives 97 | 98 | Blog Posts 99 | 100 | - https://developer.servicenow.com/blog.do?p=/post/paris-source-control/ 101 | - https://developer.servicenow.com/blog.do?p=/post/o-studio-features/ 102 | - https://developer.servicenow.com/blog.do?p=/post/source-control-cicd-resources/ 103 | - https://developer.servicenow.com/blog.do?p=/post/cicd-pipeline-github-actions/ 104 | - https://developer.servicenow.com/blog.do?p=/post/san-diego-source-control/ 105 | 106 | External Integrations, Pipeline Templates, and Getting-Started Videos 107 | 108 | - https://github.com/ServiceNow/devproductivity-guides/tree/master/pluginsAndIntegrations 109 | 110 | I recommend the GitHub Actions one as it's the most recent:  111 | - https://www.youtube.com/watch?v=mpnYwGPvMPg 112 | -------------------------------------------------------------------------------- /pluginsAndIntegrations/README.md: -------------------------------------------------------------------------------- 1 | ## Jenkins Plugin 2 | 3 | Marketplace 4 | - https://plugins.jenkins.io/servicenow-cicd/ 5 | 6 | Repos 7 | - https://github.com/jenkinsci/servicenow-cicd-plugin/ 8 | 9 | Pipeline Sample 10 | - https://github.com/jenkinsci/servicenow-cicd-plugin/tree/master/examples 11 | 12 | Setting up your first CI/CD pipeline with Jenkins (YouTube) 13 | - https://www.youtube.com/watch?v=-FDdQ_ZgWGw 14 | 15 | ## Azure Pipelines Extension 16 | 17 | Marketplace 18 | - https://marketplace.visualstudio.com/items?itemName=ServiceNow.vss-services-servicenow-cicd 19 | 20 | Repos 21 | - https://github.com/ServiceNow/servicenow-cicd-azure-extension 22 | 23 | Pipeline Sample 24 | - https://github.com/ServiceNow/servicenow-cicd-azure-extension/tree/master/examples 25 | 26 | Setting up your first CI/CD pipeline with Azure Pipelines (YouTube) 27 | - https://www.youtube.com/watch?v=ncI0etU33P0 28 | 29 | ## GitHub Actions 30 | 31 | Marketplace (Search) 32 | 33 | - https://github.com/marketplace?type=actions&query=servicenow 34 | 35 | Marketplace (Individual Actions) 36 | 37 | - https://github.com/marketplace/actions/servicenow-ci-cd-apply-changes 38 | - https://github.com/marketplace/actions/servicenow-ci-cd-install-app 39 | - https://github.com/marketplace/actions/servicenow-ci-cd-publish-app 40 | - https://github.com/marketplace/actions/servicenow-ci-cd-rollback-app 41 | - https://github.com/marketplace/actions/servicenow-ci-cd-run-atf-test-suite 42 | - https://github.com/marketplace/actions/servicenow-ci-cd-activate-plugin 43 | - https://github.com/marketplace/actions/servicenow-ci-cd-rollback-plugin 44 | - https://github.com/marketplace/actions/servicenow-ci-cd-batch-install 45 | - https://github.com/marketplace/actions/servicenow-ci-cd-instance-scan 46 | 47 | Repos 48 | - https://github.com/ServiceNow/sncicd-apply-changes 49 | - https://github.com/ServiceNow/sncicd-install-app 50 | - https://github.com/ServiceNow/sncicd-publish-app 51 | - https://github.com/ServiceNow/sncicd-rollback-app 52 | - https://github.com/ServiceNow/sncicd-tests-run 53 | - https://github.com/ServiceNow/sncicd-plugin-activate 54 | - https://github.com/ServiceNow/sncicd-plugin-rollback 55 | - https://github.com/ServiceNow/sncicd-batch-install 56 | - https://github.com/ServiceNow/sncicd-instance-scan 57 | 58 | Pipeline Sample 59 | - https://github.com/ServiceNow/sncicd_githubworkflow 60 | 61 | Setting up your first CI/CD pipeline with GitHub Actions (YouTube) 62 | - https://www.youtube.com/watch?v=OZtm4tgHVo4 63 | 64 | ## GitLab 65 | 66 | Marketplace 67 | - https://hub.docker.com/r/servicenowdevx/sncicd-gitlab-docker 68 | 69 | Repos 70 | - https://github.com/ServiceNow/sncicd-gitlab-docker 71 | 72 | Pipeline Sample 73 | - https://gitlab.com/ServiceNow-DevX/sncicd-gitlab-pipeline 74 | 75 | Setting up your first CI/CD pipeline with GitLab CI/CD Pipelines (YouTube) 76 | - https://www.youtube.com/watch?v=Y9YjThpAlm8 77 | 78 | ## Announcements 79 | - https://blogs.servicenow.com/2020/new-devops-integrations-speed-up-delivery.html 80 | - https://devops.com/servicenow-extends-devops-integration-reach/ 81 | - https://www.devopsdigest.com/servicenow-announces-new-devops-integrations 82 | - https://digitalanarchist.com/videos/featured-guests/marcus-torres-techstrong-tv 83 | - https://developer.servicenow.com/blog.do?p=/post/creatorcon2020-intro/ 84 | - https://events.servicenow.com/widget/servicenow/creatorcon2020/creatorconschedule/session/1601571966226001aL9U#1602085423551001RF9p 85 | - https://github.blog/2020-12-09-building-together-github-partner-ecosystem-continues-to-grow/ 86 | - [Youtube Video](https://www.youtube.com/watch?v=r_7NdEyvRYk) GitHub Universe 2020, Partners, ServiceNow GitHub Actions for CI/CD. [GitHub Universe 2020 Day 2](https://www.youtube.com/watch?v=SqAJsCpHL_E) 87 | - https://developer.servicenow.com/blog.do?p=/post/cicd-pipeline-github-actions/ 88 | 89 | ## CICD Spoke on Flow Designer 90 | 91 | Using Flow Designer and the CI/CD Spoke to setup a basic pipeline on Platform 92 | - https://www.youtube.com/watch?v=rj3TSK1RAYA 93 | -------------------------------------------------------------------------------- /pluginsAndIntegrations/contribute_template.md: -------------------------------------------------------------------------------- 1 | ## Contribution Model 2 | 3 | Contributions to help improve this integration are more than welcome. As is standard workflow, please fork the project to your own repo, create a branch to commit your changes to, then submit a pull request back to this project. An open-source community maintainer will then help to review the changes and merge the pull request if the changes are approved. A new version of the integration will then be published onto the respective marketplace. In your pull request, please include the following where applicable: 4 | 5 | 1. Description of the problem solved. Include Issue link if there is one. 6 | 2. Acceptance criteria for how an approver can tell if the "story" was completed. 7 | 8 | If your changes involve code, please update the unit tests as well. 9 | -------------------------------------------------------------------------------- /pluginsAndIntegrations/governance_template.md: -------------------------------------------------------------------------------- 1 | ## Governance Model 2 | 3 | Initially, ServiceNow product management and engineering representatives will own governance of these integrations to ensure consistency with roadmap direction. In the longer term, we hope that contributors from customers and our community developers will help to guide prioritization and maintenance of these integrations. At that point, this governance model can be updated to reflect a broader pool of contributors and maintainers. 4 | -------------------------------------------------------------------------------- /pluginsAndIntegrations/opensource_kb.md: -------------------------------------------------------------------------------- 1 | ## Open-Source and ServiceNow Support 2 | KB article draft for ServiceNow Support teams on how to respond to inquiries on open-source projects and tools from customers. 3 | 4 | Open-source projects are intended to leverage community-driven collaboration from maintainers and contributors to maintain and improve the software. Some of the key benefits: 5 | - If you're a user of the software and find a bug or see potential improvements to be made, you can help to document and then contribute a pull request to address the changes. 6 | - Changes from the community can be much faster to implement, allowing for a more iterative, agile development model, resulting in features getting out to everyone using the project faster. 7 | - More eyes on the code means more rigor in maintaining the codebase. 8 | 9 | For ServiceNow customers, this translates to a few key things to be aware of: 10 | - Customers need to evaluate the risk of relying on an open-source project that is not formally supported by ServiceNow. 11 | - Customers can consider providing engineering bandwidth to help contribute to fix bugs or make feature enhancements. 12 | - Customers can have a strong influence over the roadmap of these open-source projects as maintainers and contributors by supporting development. 13 | 14 | For any further questions, please submit Issues to the relevant open-source project. 15 | -------------------------------------------------------------------------------- /pluginsAndIntegrations/support_template.md: -------------------------------------------------------------------------------- 1 | ## Support Model 2 | 3 | ServiceNow built this integration with the intent to help customers get started faster in adopting CI/CD APIs for DevOps workflows, but __will not be providing formal support__. This integration is therefore considered "use at your own risk", and will rely on the open-source community to help drive fixes and feature enhancements via Issues. Occasionally, ServiceNow may choose to contribute to the open-source project to help address the highest priority Issues, and will do our best to keep the integrations updated with the latest API changes shipped with family releases. This is a good opportunity for our customers and community developers to step up and help drive iteration and improvement on these open-source integrations for everyone's benefit. 4 | -------------------------------------------------------------------------------- /replaceTeamDev/README.md: -------------------------------------------------------------------------------- 1 | # Team Development Feature Parity is based on Needs 2 | 3 | | Team Development | Need | Studio, Source Control, App Repo, and CI/CD | 4 | |----------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 5 | | Detecting and resolving conflicts prior to promoting | Code validation to minimize risk of production outage | Automated test coverage (e.g. ATF) as a part of running a CI build that triggers on source control Pull Request to merge feature branch into master branch | 6 | | Large teams with many dev instances pull/push changes to a dev master to merge their changes before pushing up the stack (test, stage, prod, etc.) | Supporting many developers and teams each working on their own feature/bug stories and delivery cadence | Separate applications and separate branches, use Git flow to merge via Pull Requests. Many dev instances if working on the same app but different branches. | 7 | | See where a set of changes are in their promotion journey. | Visualization for which “stage” a code change is in | Jenkins, Azure Pipelines, other popular CI/CD tooling provide ability to define stages and visualize progress as the pipeline runs. | 8 | | Enforce pull before push between parent and child instances | Merging code to detect conflicts prior to deploying code. | Use Git branches and Pull Requests, code conflicts will automatically be detected between branches prior to merge. Publish, install, rollback applications when validating in test environments. | 9 | | Do everything on-platform. | Reduce number of tools to manage. | Customers benefit from adopting integration with Git repos and workflows, as it’s the standard for software development today. We provide both on-platform and off-platform options for building CI/CD pipelines. | 10 | | Update sets work for global, scoped, and Store/OOTB customizations. | Use one development model for everything, especially for global file customizations. | Post-Quebec, Source Control will work for scoped apps, global apps (Paris), and Store/OOTB customizations (Quebec). You’ll also be able to move these apps through App Repo either via UI or CI/CD APIs. | 11 | 12 | Thanks to [tablesgenerator](https://www.tablesgenerator.com/markdown_tables#) for easy markdown conversion. 13 | -------------------------------------------------------------------------------- /withDevOps/README.md: -------------------------------------------------------------------------------- 1 | **What is DevOps, and what is Dev@Scale (Source Control, CI/CD)?** 2 | 3 | "ServiceNow DevOps" automates change management and progress dashboards for apps built anywhere. 4 | 5 | "ServiceNow CI/CD" helps customers building apps on SN to automate testing and deployment. 6 | 7 | ![](https://github.com/ServiceNow/devproductivity-docs/blob/master/withDevOps/Summary.png) 8 | 9 | **Qualifying Questions** 10 | 11 | When a customer says, "I want DevOps", or "I have Jenkins", we need to help them drill down on their specific user needs, because those are very generic buckets. What are they thinking of solving with "DevOps"? What are they using Jenkins to do? 12 | 13 | 1. Clarify what applications they are building and where. 14 | 1. If it's off-Platform (e.g. Java app, mobile app, built by other teams in the company), Now Platform CI/CD does not apply. They might want to use ServiceNow DevOps for change management and viewing progress in one place. 15 | 2. If it's on-Platform, then we need to keep asking questions, but they could very well need both CI/CD and DevOps. 16 | 2. Clarify the need in relation to external tools. 17 | 1. If it's to track and monitor build progress in one place, then they want ServiceNow DevOps for its Insights Dashboard. 18 | 2. If it's to add approval steps (change management) in an automated fashion, then direct to ServiceNow DevOps. 19 | 3. If it's to use external tools as the code repository or build automation server to automate testing and deploying of apps being built on the Now Platform, then point to our CI/CD features. 20 | 3. Clarify what type of automation they are seeking 21 | 1. Automating change management requests → ServiceNow DevOps 22 | 2. Automate mechanics of deploying code into environments (via App Repo) → CI/CD 23 | 24 | **The Sweet Spot (1+1=3)** 25 | 26 | Now Platform CI/CD → External Build Tools → ServiceNow DevOps 27 | 28 | Use Jenkins as the build automation tool for automating testing and deployment of apps on the Now Platform. 29 | 30 | Then feed the pipeline data from Jenkins (for any applications, not just Now Platform apps) back to ServiceNow DevOps to automate generation of change request stories and see progress in one Insights Dashboard. 31 | -------------------------------------------------------------------------------- /withDevOps/Summary.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ServiceNow/ALM/aa7495555334d2d55b68963197cc88194234aff5/withDevOps/Summary.png --------------------------------------------------------------------------------