Might it be helpful to have different levels of scrutiny?
The strictest would be for changes which pose a risk of corrupting the database.
Medium is for “read-only” features, but those which are essential for the system to work, like displaying time-critical information.
Least for report generation systems in which unavailability can be tolerated.
If a bug gets in the report that the accountant uses for example, it could be a higher priority
That can be classified as corrupting the database.
I was thinking more in terms of reports for statistical analysis.
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:
From a developer’s POV:
From DMS’s POV:
From the member’s POV:
How does this help us with testing the RSS feature?
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 >>
)
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?
We will have to teach a class on it, you do realize that 
Application configuration and static files:
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
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.
On Prod? I didn’t know we were running docker on prod already
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.
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.
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.
good chance it wasn’t updated. we’ll have to ssh in and see if there’s a git change log.
git blame
Here is the commit where I corrected the fatal bug
I’m thinking that it was updated from a private git repo someone had … files just copied up there … I don’t know
Check what the remotes are set to as well. …
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.
Me too.
Whatever squeeze you guys have to go through, the juice will be worth it.
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.
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 Subscribe to someone’s Google Calendar - Computer - Google Calendar Help.