Q: How would you describe your demanor and how does that contribute to the outcome in a client engagement?
Q: When a customer says "We have all kinds of GHE problems and need your help." how would you narrow that down to a set of tasks that could be put into a statement of work?
Q: What tactics would you employ to suss out what the real (not just perceived) needs of a client are via a phone call?
Q: What is a process or criteria that you use to evaluate any kind of opportunity, such as a new technology, a new product feature, or a prospective client engagement?
Q: What are criteria by which you might prioritize the requests the Sales team makes of the Services team?
Q: What is a GitHub Integration that you find invaluable? Why do you find it useful?
Q: Have you investigated personal access tokens vs. OAuth flows for tools that use the GitHub platform?
Q: What type of questions do you find yourself asking in past client engagements?
The Git version control system and GitHub collaboration platform offer a myriad of innovative and classic development workflow options. The wide range of opinions about these on the Internet can make it challenging to nimbly make wise Git workflow decisions for your team's next project.
In this presentation, Matthew will provide a tour of successful workflow patterns harvested from 7 years of studying and working with open source projects, small and large scale businesses, and governmental agencies employing everything from waterfall to fully agile processes. Flows will feature live demonstrations of the supporting Git and GitHub commands.
A little guidance can go a long way in helping you navigate the new world of distributed version control, and this talk will help you make informed choices of the Git features you'll use, the branching patterns you'll leverage, and the way you will integrate your chosen pattern with your team's development practices.
I hereby claim:
To claim this, I am signing this object:
| layout | title | description | path |
|---|---|---|---|
bare |
Continuous Delivery |
The next step in the evolution of software development is making ever smaller changes and continually deploying to production. |
technology/_posts/2001-01-01-lesson-continuous-delivery.md |
Continuous delivery is the current buzz, but let's take a few minutes to demystify it. 1. Does it work? 2. How would you go about getting towards that mode of operation? 3. Why would you want to have continuous delivery? 4. What tools facilitate this? You'll leave a transformed developer. The idea of releases being non-stressful and able to be merged in on Friday at 4pm is attractive to the majority of us who have suffered at the hands of the "awful rollback" and the "long weekend." These travails are partially the result of being on the opposite end of the spectrum from continuous delivery. Come with an open mind to branching strategies, feature toggles, and Readme-driven development.
| (* | |
| ====================================== | |
| // CONFIGURATION (USER EDITABLE) | |
| ====================================== | |
| *) | |
| --CHANGE THIS PROPERTY TO THE HTML CODE YOU'D | |
| --LIKE TO ADD TO THE BEGINNING OF YOUR NOTE. | |
| --(DEFAULT IS 5 LINE BREAKS AND A HORIZONTAL RULE) | |
| property add_to_top : "<hr/>" | |
| (* |