Something never seen on the Events Calendar - Live Now

DMS General
#24

changes which pose a risk of corrupting the database

The framework we’re using has an Object Relational Model which means things in the database look and feel like class objects in the code. So changes there can be unit tested before even hitting the production or any database at that. We’re also able to introduce mock tests which supply a temporary in ram database filled with test data that we run automated test units on to verify we’re working as expected.

We’re also moving more to a 12 Factor application design model with Behavior Driven Development so this would be less than likely to be an issue at all but still an item that needs to be approved via the Pull Requests and change approval process.

yes I’m aware of how much that sounds like red tape and extra steps but its not. Just means developers fork the code then submit pull requests to github which have unit tests written first then code to make the unit tests work. When the pull request is submitted the cicd (travis-ci) runs all the tests. If it fails then nothing goes upstream from there. if it passes then we tag the master branch for release using semantic versioning (ie v1.0.0) and the new release gets push into the production cluster.

different levels of scrutiny?

This breaks down like this:

  • Committee chairs and other stakeholders attend the Development Priority Meeting to select items for sprint & groom the backlog
  • developer picks available tickets selected for the sprint
  • developer creates unit tests
  • developer writes only enough code to make unit tests pass
  • developer commits code and submits a pull request to the development branch on github
  • travis-ci test code on pull request and emails development team (also shows up as an alert bell on github)
  • review process of code begins, if acceptable pull request is accepted
  • docker hub builds image for “latest” release
  • community grid auto deploys “latest” release to development systems
  • developer team then can run end to end tests and acceptance tests
  • with passing all the above the “latest” gets blessed with a semver tag
  • docker hub builds the version tagged release
  • developer team logs into the community grid and bumps up the production tagged version to the new release
  • community grid deploys the the tagged version into production.

From a developer’s POV:

  • Write tests, run tests, write lease amount of code needed
  • run tests again and do a pull request
  • Sip coffee/beer and have fun making things for DMS

From DMS’s POV:

  • Only needed predefined changes are picked and available for work
  • All the things are tested and bugs squashed before it hits the servers / membership
  • Able to track issues to which release and able to roll back to a working known working state with a push of a button
  • Sip coffee/beer knowing things get done and members are happy

From the member’s POV:

  • New features and things just work
2 Likes
#25

How does this help us with testing the RSS feature?

https://qafoo.com/blog/007_practical_phpunit_testing_xml_generation.html

Write the unit tests with mock data and make sure the rss is rendered correctly.

Deploy to the preprod cluster and point things at it.

How can we verify what is on production is what is in master?

The Audit log. Semantic Versioning of docker images and releases in github.

Touch a littlle on this one with my reply to bill but it works like this:

  • github code in master gets tagged as 1.0.0

  • docker image in docker hub gets the same tag.

  • docker image tagged ‘latest’ is the same code in master.

  • tag code in github as 1.0.2 and it goes down the line to docker hub as tagged 1.0.2

  • travis-ci follows this same process as well under the build history log.

  • we’re also able to tag logs in the community grid based on both container and image names. (e.g. container: preprod/calendar image: dallasmakerspace/calendar:1.0.0 msg: << HTTP ERROR LOG >>
    )

1 Like
#26

The preprod cluster will be on the internet and not just the intranet, correct?

Alright. Where do I find that? Does it take into application configuration and static files?

How will it bring in the specific configuration for the instance?

1 Like
#27

We will have to teach a class on it, you do realize that :stuck_out_tongue:

1 Like
#28

Application configuration and static files:

https://12factor.net/config

Store config in the environment
An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes:

  • Resource handles to the database, Memcached, and other backing services
  • Credentials to external services such as Amazon S3 or Twitter
  • Per-deploy values such as the canonical hostname for the deploy

We’re already doing some of that in the source There’s a few areas that need to be touched. and its applied with the docker-compose.

For static content that should either be in aws s3 or the code repo’s webroot directory.

We will have to teach a class on it, you do realize that :stuck_out_tongue:

Yes! we do and that’s one of the classes I’ve been wanting to get out the door sooner than later. Its a main staple class too, one that everyone I talk to when doing avocation and recruiting wants to take.

1 Like
#29

On Prod? I didn’t know we were running docker on prod already

2 Likes
#30

Audit log

Here’s the links as of right now:

there’s no syslog or deployment logs at this point since what’s on the old vm is manually deployed which is not how we want to do deployments.

1 Like
#31

running docker on prod already

I have a few VM’s out in aws that need to be joined into a cluster and green code deployed. I’d consider those UAT environments until we actually show stablity in the system.

1 Like
#32

Ok, but this doesn’t show what is on prod currently … we need a diff between master and prod before we update too much
I found an error in master that would make the software not work right. Since it is working on prod, it can’t be the same.

1 Like
#33

good chance it wasn’t updated. we’ll have to ssh in and see if there’s a git change log.

git blame

1 Like
#34

Here is the commit where I corrected the fatal bug

1 Like
#35

I’m thinking that it was updated from a private git repo someone had … files just copied up there … I don’t know

1 Like
#36

Check what the remotes are set to as well. …

1 Like
#37

I don’t really know what is or isn’t going on with the testing, but I would/will be thrilled to have RSS functionality added to the events page.

2 Likes
#38

Me too.

Whatever squeeze you guys have to go through, the juice will be worth it.

2 Likes
#39

I don’t know if I mentioned this but it generates a feed for every selection. For example, if you want a Blacksmithing feed, you will have one.

2 Likes
#40

It’s not RSS, but just wanted to remind people that this exists.

https://calendar.dallasmakerspace.org/events/feed

you can add it to your google calendar by following the “Add by link” instructions on this page https://support.google.com/calendar/answer/37100?co=GENIE.Platform%3DDesktop&hl=en.

2 Likes
#41

Your right, its not RSS and there’s no aggregation of events since that’s just a vCalendar event. Not all of us live inside our outlook / email clients. But those that do I’m sure a vcalendar event is fine for them.

#42

Sheesh… could that line be any longer? Don’t get me wrong, 80 column code is the thing of the past sure but at lease lets have it read able within 120 columns?

#43

@Draco @LukeStrickland Guys, make sure your pulling down upstream changes as well when submitting changes. I’m seeing errors reported in travis-ci that’s I’ve already corrected.